CC: SG16 Unicode

It has been brought to my attention by Victor Zverovich that
filesystem::path has an unfortunate quirk wrt Ranges:
filesystem::path::iterator::value_type is filesystem::path. This means
that generic Ranges-based code such as:

```
#include <filesystem>
#include <iostream>

template< class T >
concept Range = requires(T&& t) {
  std::begin(std::forward<T>(t));
  std::end (std::forward<T>(t));
};

template <typename T>
void print(const T& value) {
  std::cout << value;
}

template <Range R>
void print(const R& range) {
  for (const auto& elem: range) {
    print(elem);
  }
}

int main() {
  print(std::filesystem::path("foo"));
}
```

... loops infinitely.

Seeing as LEWG endorsed in Cologne path_view departing from path's
design where it makes sense, I therefore propose a design change to
P1030 filesystem::path_view: its iterator should no longer return
another filesystem::path_view, but filesystem::path_view_component.
filesystem::path_view_component would have all the member functions
which filesystem::path_view has without those pertaining to paths of
more than one component, or iteration. These currently would proposed to be:

.empty()
.native_size()
.swap()
.contains_glob()
.stem()
.extension()
.path()
.compare()

Note the lack of .size(), and especially begin() and end().

filesystem::path_view_component would not be constructible by public
code, only from a filesystem::path_view member function.

filesystem::path_view would implicitly construct from
filesystem::path_view_component.

Is LEWG happy with this proposed design change?

Niall