Merge pull request #2866 from Geod24/mlang/Simplify1 ...

Trivial: Simplify PackageManager's loadInternal

Move writing selections file to PackageManager ...

The PackageManager is the main source of IO in Dub,
and having it take responsibility for writing the
selections file reduces the number of special casing
we need to make when doing dependency injection.

Simplify condition.

Trivial: Simplify PackageManager's loadInternal

Properly fix issue #2691 by reverting to the original scanning behavior. ...

Reverts to the scanning/warning behavior that was in place before the warnings for the new package directory structure were implemented.

Revert "Fix #2691: Use same structure for managed and unmanaged path" ...

This reverts commit 1a53049.

PackageManager: Move addPackages inside loadGitPackage ...

This avoids calling addPackages when the package is already loaded,
and will allow us to handle PlacementLocation correctly in the future.

Allow better dependency injection on PackageManager's SCM operation ...

What we really want to override is the git clone operation,
so one way to approach this is to decouple it from the rest
of the code, then when our virtual filesystem is complete,
we will only need to override that one function.

Trivial: Slightly simplify PackageManager.store

Merge remote-tracking branch 'upstream/stable' into merge_stable

Do not allow for removal of subpackages ...

Because it can mess up the system quite dramatically.

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

Remove PackageName alias this to toString ...

The alias this was originally added to make the transition
less painful, however due to an overload resolution bug,
it makes it harder at the moment, as thje compiler prefers
calling the deprecated `string` overloads over the
`in PackageName` ones. So remove it and a few hacks along
the way.

Trivial: Align PackageManager's lookup signatures

Deprecate Package.getInternalSubPackage, simplify DepedencyResolver ...

The PackageManager will always eagerly load subpackages,
whether they are path based or embedded (see addPackages).
So calling getInternalSubPackage if getSubPackage returned
null will never yield a non-Nullable object.
In short, we can simplify that code greatly, and as
Package.getInternalSubPackage does not handle all use
case and require using the PackageManager anyway, just
deprecate it and direct people to the right function.

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.

Simplify PackageManager.getPackagePath ...

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

Trivial: Make PackageManager.addPackages protected ...

So that it can be reused in the TestPackageManager.

Introduce PackageName, to fully type a package name ...

Package names being passed around in the Dub codebase are string,
which is problematic as it suffers from validation / semantic issues.
Validation because we cannot impose restrictions on characters
or length easily, and semantic because some functions expect a main
package while some would accept a subpackage. Introducing a type
will remedy both those issues.

Fix #2691: Use same structure for managed and unmanaged path ...

Currently, we issue a warning asking people to migrate, but the migrated
path is not actually recognized. It was suggested in the issue to ignore
this warning for add-path. However, as add-path is a rather low-level
use, I think it is better to impose the same condition for managed and
unmanaged path, in order to be able to provide the same guarantees.
For example, once we move to reading version from the path,
we can provide the same speedups for add-path users.
We can also make sure that add-path users don't have surprises when
dealing with packages that expect a certain structure outside their
directory, such as arsd and ae.
Some tests were updated with the new path, however, as many will likely
be rewritten with the new test framework, and a lot of tests are affected,
not all of them were updated, providing coverage for the old and new
code alike.

Only check if the Package is managed by the Location in lookup ...

Previously, we were calling back into the PackageManager to check
if the Package we were looking at was managed.
However, as we are only iterating on Packages that are in fromPath,
we should be able to rely on the Location.isManaged property,
instead of PackageManager.isManagedPackage, which just calls
Location.isManaged for each Location.

Trivial: Add a isManaged property to Location ...

Since isManagedPath is only used from PackageManager,
we want to move to a more fine grained approach,
starting with the Location.
At the moment the Locations iterate over all the Locations,
via the PackageManager, when they could realistically
just check if the Package they are dealing with is managed by them,
as it would be a bug to have a Package from one Location passed
to another.

Revert "Simplify PackageManager's Location.lookup" ...

This reverts commit 44852b8.

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.

Simplify PackageManager's Location.lookup ...

The VersionMatchMode is a property of the Location,
not a property of the package, hence we can make
use of a Location attribute to get it,
removing a dependency on the PackageManager
and streamlining the code.

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: 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).