Tests: Use TestDub FSEntry constructor for more accurate tests ...

The previous approach added Packages in the PackageManager directly,
completely sidestepping the scanning the PackageManager does,
which is a behavior we absolutely want to test.

By setting up the filesystem before we instantiate our `TestDub` instance,
we can remove a bunch of exceptions / overrides, and get a much closer
behavior to the final product.

Tests: Fix vfs paths on Windows ...

With our versioned path implementation, we have the following issue:

assert(NativePath("/foo").absolute); // Passes
assert(NativePath(NativePath("/foo").toNativeString()).absolute); // Fails

However, instead of fixing the implementation, we provide
a different root for the VFS, which is arguably simpler but
also more correct.

Tests: Fix writeFile implementation with vibe-d ...

This was triggering an assert error with vibe-d path.
The recursion logic was a bit murky, so the function
is now split in 3 different part and better documented.

Tests: Simplify loadSCMPackage implementation ...

Now that we can override the git clone operation and load
from the virtual filesystem, we can remove a lot of the
duplicated logic. This is currently hardcoded to a dub.json,
but future iterations can store an FSEntry representing the
full package.

Tests: Add the ability for TestDub to use an initialized filesystem ...

This way, we can test any kind of crazy conditions found in bug reports,
such as the behavior in the face of non-writeable filesystem.

Tests: Move root FSEntry from PackageManager to TestDub ...

This way we can extend its use to all of TestDub.

Trivial: Make TestDub.ProjectPath a NativePath ...

If unittest code wants to reference it, it will be much more useful as NativePath.

Improve unittest framework to have a virtual FS ...

This gets the unittest framework closer to the actual behavior,
and allows us to mock basic FS operations such as mkdir and writeFile.
Further improvements can be made to support more operations,
and to have package setup done before `TestDub` instantiation.

Adapt PackageManager.get[Best]Package to PackageName API ...

This paves the way to be able to automatically return subpackages.

Adapt loadSCMPackage to PackageName API

Adapt PackageSuppliers to PackageName API ...

Since we recently did a semi-breaking change to PackageSuppliers,
now is the time to do it again (they will be in the same release).
Again the same logic applies: it's only a breaking change for those
inheriting from PackageSupplier, not those calling it,
and there is likely not a lot of people doing either out there.

Adapt getPackagePath to PackageName API ...

Now that we have the PackageName type, we need to
go through API and decide what the string means.
Multiple places expect a main package, and only
some expect a subpackage. Starting from the bottom,
it is impossible to call getPackagePath with
a subpackage, as the package path of that subpackage
depends on the main package. However, we want to be
lax here, so always return the main package path.

Expand selections file handling to handle new versions ...

Up until now, the selections file has had a `fileVersion` in it,
but that number was always stuck to 1.
In order to make it possible to handle more than one version,
a bit of scaffolding needs to happen in the config parser.
This lays the ground for a version 2 of the selections file.

Simplify PackageManager.getPackagePath ...

All callers ended up appending to the returned path,
so just do it in getPackagePath and save ourself some trouble.

Testsuite: Add more structured paths ...

So we can start replicating the filesystem in unittests.

Make PackageManager.load non-const ...

It was made const to satisfy PackageManager.addPackages, but that
method actually takes a field of the PackageManager as ref parameter,
so it can never be called from a 'const' context, and while implementing
'TestPackageManager.load', it was found that 'const' wasn't suitable.

Dub.loadPackage: Error out if no recipe is found ...

Before, due to calling Project.this(PackageManager, NativePath),
using loadPackage when no PackageRecipe exists would lead to
an error message being printed from the ctor and the Project
being initialized with an empty recipe.
Such a behavior should not be implicit - instead, we will now
error out directly from loadPackage if no Package is found.

A nice side effect is that it also allows us to re-defined
one overload in terms of the other, simplifying subclasses
implementations.

Deprecate `Package.load`, use `PackageManager.load` instead ...

In order for the dependency injection approach to work,
we need to be able to override every single instance of
`Package.load`. We could not override `Package.load` itself
as it is a static function.
However, in the process of adding support for path-based dependencies
to the test suite, it became obvious that the functionality offered
by `Package.load` is actually better suited for the `PackageManager`.
Deprecating `Package.load` confirms this: Not a single call was outside
of `PackageManager`, and no extra parameter had to be provided anywhere
to make this work.
This also nicely simplifies the `TestPackageManager` implementation,
as we can now overload `load` and let `getPackage` alone.

Test framework: Add documentation and an example UT

Fix #2696: Segfault with bad dub.sdl ...

This was a null pointer being passed down.
However, while looking at the code, it was obvious that similar
bugs would trigger for subpackages (as the code was not handling
`null` packages either), so test cases for those have been added.

Test framework: Return fully typed TestPackageManager from TestDub ...

Using covariant return type, we can avoid the need to change the base class,
and leave all the overloading in the child class.

Add unittest framework and some dependency tests ...

Dub has always been notoriously hard to test due to the amount of IO it does.
Over the past few years, I have progressively refactored it to allow
dependency injection to take place, which this finally put into action.
By overriding the `PackageManager`, `PackageSupplier`, and a few strategic
functions, we can start to unittest Dub's behavior solely in unittests.
This should hopefully tremendously helps with adding regression tests
for the package manager side of Dub (the build side still need work
to have similar capabilities).

Allow dependency injection on the PackageSupplier ...

In order to make the `Dub` class properly unittest-able,
we need to be able to use a non-default `PackageSupplier`,
in particular one that would not hit the registry or the filesystem.
This can be achieved by moving a free function to a method and having
derived class override it, as shown in this commit.

Move TestDub to its own module ...

As we will begin to inject more dependencies, having a base module makes sense.