Path Contexts

We'll need a file system API for virtual paths. Local path (#1) should implement the same API, so it should be possible to abstract over both kinds of paths.

The API should allow to:
- manipulate foreign paths, e.g. Windows paths on a Linux computer, and vice versa;
- introduce fully virtual file systems.

Currently, I am thinking of adding a new field of type `IFileSystem` or `IPathContext` to each of our path types: hopefully, this won't create too much overhead for their storage.

Default constructors would rely on a singleton instance for the current system, something like `new LocalPath("foo") => new LocalPath("foo", LocalFileSystem.Instance)`.

There should be a way for the user to introduce custom path validation in constructor. For example, if they want to somehow avoid Windows paths on Linux and want to throw on `new LocalPath(CustomContext, @"C:\Windows")`, even though this path is valid.

## TODO
- [ ] Introduce a field into all `*Path` types.
- [ ] Derive the path manipulation operations to the path context:
- [ ] path separators,
- [ ] behavior aspects such as Windows drives,
- [ ] path validation in constructors (even for `LocalPath` that doesn't do any validation otherwise).
- [ ] Allow passing the context to path constructors.
- [ ] The constructors should delegate to some `LocalPathContext.Instance` by default (if nothing else is passed).
- [ ] `LocalPathContext.Instance` should be a writable field (for global custom override).
- [ ] Future enhancement request: allow `ThreadLocal` and/or `AsyncLocal` override for `LocalPathContext`, to avoid reliance on the global state.

No files or tests are named. Start by locating the existing *Path types and LocalPath, then trace their constructors and path-manipulation operations. Done means those types share a path-context API supporting separators, platform behavior, validation, custom constructor contexts, and the default LocalPathContext.Instance behavior described in the TODO.

Written by the indexing model from the issue text.