Following bpo-39899, bpo-43757 and bpo-43012, `pathlib._Flavour` and its subclasses are looking a bit pointless.

The implementations of `is_reserved()` and `make_uri()` (~`as_uri()`) can be readily moved to into `PurePosixPath` and `PureWindowsPath`, which removes some indirection. This follows the pattern of OS-specific stuff in `PosixPath` and `WindowsPath`.

The remaining methods, such as `splitroot()`, can be pulled into `Pure*Path` with an underscore prefix.

I'm generally a believer in composition over inheritance, but in this case `_Flavour` seems too small and too similar to `PurePath` to separate out into 3 extra classes.

There should be no impact on public APIs or performance.

Depends: bpo-39899, bpo-43757, bpo-44316, bpo-44403, bpo-44412

^ just to bring my previous comment up-to-date:

I'm no longer pursuing adding `os.path.isreserved()` and `os.path.fileuri()` functions, or modifying `normpath()`. At least, not for now!

Instead, my plan is to move flavour functionality as follows (as classmethods with underscore prefixes):

  _Flavour        --> PurePath
  _PosixFlavour   --> PurePath
  _WindowsFlavour --> PureWindowsPath

As a result, PurePath will use POSIX syntax by default. This is fully backwards-compatible, as users can't create PurePath objects! PurePath.__new__() instantiates PurePosixPath or PureWindowsPath. But it will matter for future user subclasses of PurePath/Path, where we usually want POSIX syntax.

I think there will be three PRs involved. PR 30320 and PR 30321 move _Flavour.make_uri() and _Flavour.is_reserved() respectively; these are reasonably standalone. If/when they land, I'll make a larger PR that moves the remaining methods into PurePath and PureWindowsPath.