[VFS] Allow multiple RealFileSystem instances with independent CWDs.

[VFS] Allow multiple RealFileSystem instances with independent CWDs.

Summary:
Previously only one RealFileSystem instance was available, and its working
directory is shared with the process. This doesn't work well for multithreaded
programs that want to work with relative paths - the vfs::FileSystem is assumed
to provide the working directory, but a thread cannot control this exclusively.

The new vfs::createPhysicalFileSystem() factory copies the process's working
directory initially, and then allows it to be independently modified.

This implementation records the working directory path, and glues it to relative
paths to provide the correct absolute path to the sys::fs:: functions.
This will give different results in unusual situations (e.g. the CWD is moved).

The main alternative is the use of openat(), fstatat(), etc to ask the OS to
resolve paths relative to a directory handle which can be kept open. This is
more robust. There are two reasons not to do this initially:
1. these functions are not available on all supported Unixes, and are somewhere
   between difficult and unavailable on Windows. So we need a path-based
   fallback anyway.
2. this would mean also adding support at the llvm::sys::fs level, which is a
   larger project. My clearest idea is an OS-specific `BaseDirectory` object
   that can be optionally passed to functions there. Eventually this could be
   backed by either paths or a fd where openat() is supported.
   This is a large project, and demonstrating here that a path-based fallback
   works is a useful prerequisite.

There is some subtlety to the path-manipulation mechanism:
  - when setting the working directory, both Specified=makeAbsolute(path) and
    Resolved=realpath(path) are recorded. These may differ in the presence of
    symlinks.
  - getCurrentWorkingDirectory() and makeAbsolute() use Specified - this is
    similar to the behavior of $PWD and sys::path::current_path
  - IO operations like openFileForRead use Resolved. This is similar to the
    behavior of an openat() based implementation, that doesn't see changes
    in symlinks.
There may still be combinations of operations and FS states that yield unhelpful
behavior. This is hard to avoid with symlinks and FS abstractions :(

The caching behavior of the current working directory is removed in this patch.
getRealFileSystem() is now specified to link to the process CWD, so the caching
is incorrect.
The user who needed this so far is clangd, which will immediately switch to
createPhysicalFileSystem().

Reviewers: ilya-biryukov, bkramer, labath

Subscribers: ioeric, kadircet, kristina, llvm-commits

Differential Revision: https://reviews.llvm.org/D56545

llvm-svn: 351050