Support executing require in dynamically generated, library-aware virtual filesystems

[vrn-sn]

This PR introduces Library::RequireVfs as an alternative to RequireVfs (the current abstraction around the filesystem, @std libraries, @lute libraries, and [optionally] CLI commands).

To accomplish this, we introduce IRequireVfs as a shared interface in require.h that both RequireVfs and Library::RequireVfs implement; RequireCtx now simply contains a std::unique_ptr<IRequireVfs>.

At a surface level, Library::RequireVfs's logic is fairly similar to RequireVfs's. Our RequireVfs implementation can be in any of the following VFS types at a given moment: Disk, Std, Cli, Lute. Similarly, Library::RequireVfs can be in any of the following: Library, Std, Lute.

The default VFS type (for example, when code execution of a project begins) for Library::RequireVfs is Library. In this case, Library::RequireVfs manages an internal Library::Vfs, which itself can be in one of two VFS states: Disk or Subtree. Conceptually, the Disk case is used to execute user code, and Subtree is used for executing code in installed libraries.

To enable executing code that relies on installed libraries, Library::Vfs must be constructed with two arguments:

1. directDependencies: the list of all libraries that user code directly depends on.
2. libraries: the list of all transitive dependencies of the user code, with their dependencies on each other also passed in explicitly.

What this enables: when executing user code (in Disk mode), we are able to dynamically inject aliases to the libraries indirectDependencies that, when followed, transition Library::Vfs into Subtree mode. Then, when executing library code (in Subtree mode), we are able to use the dependency information passed in via the libraries constructor argument to inject aliases to each library's direct dependencies.

Because this happens on a per-library basis, an alias @dep doesn't need to mean the same thing in library1 and library2. Although it is still true that user code and any individual library cannot directly depend on multiple versions of a dependency, multiple versions are completely fine in the set of transitive dependencies.