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.

Testsuite: Add more structured paths ...

So we can start replicating the filesystem in unittests.

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.

CommandLine: Make better use of UserPackageDesc

CommandLine: Rename PackageAndVersion, slightly refactor, document

CommandLine: Store a VersionRange, not a string, in PackageAndVersion ...

Typing this parameter means that places know they have a valid
version on their hand as opposed to a string everyone need to
validate and verify.

Deprecate Project.this(PackageManager, NativePath) ...

This overload was originally only used from Dub.loadPackage(NativePath)
before it was changed (although the Project should only ever be instantiated
from the Dub class). But it is doing IO and its soft failure approach
is a misfeature, hence we deprecated it.

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.

platform: add support for LoongArch

Trivial: Simplify Project.reinit by removing nested functions ...

When 95% of your function is nested, you're doing it wrong.
Move the function to be at the class level and private,
which makes the logic easier to follow and reduces indentation.

Trivial: Document Project.reinit ...

Arguably one of the most important method on the package management
front, as it is handling the logic of what dependencies will be used
in most cases (the DependencyResolver is only called when deps are
missing, but most projects have a dub.selections.json).

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.

update version to v1.36.0-beta.1

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

update version to v1.35.1

Test framework: Add documentation and an example UT

Deprecate Project.packageManager ...

There is no reason to expose the PackageManager through the Project.
In fact, the only two places it was used were in generators,
where the PackageManager was stored but never used.
The generators arguably should not have access to the PackageManager,
as all the Packages should have been loaded and handled to them
before the generation starts.

Remove fallback to ~master on dub fetch, fix #2679 ...

The retry does not make sense, as one cannot add a package
to the registry without a release version.
It is also not in line with Dub strategy, as we are trying
to reduce the usage of branch dependencies.

This also fixes issue #2679 which pointed out the error message
was sub-par. The API of the registry seems to have changed and
we now get `null` instead of `undefined`, leading to an error
inside the JSON module instead of the enforce being triggered.

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 PackageManager ...

We want to allow one to provide their own PackageManager instance.
There are 3 standard ways of doing this:
1) Provide an instance in the constructor;
2) Provide a template parameter;
3) Use a hook that is called by the constructor;

We are going with option 3 as the other two methods have clear downsides:
Option 1 exposes too much of the implementation detail (even if it can
be wrapped by another constructor) and makes the dependency to internal
state hard / impossible (we need to instantiate SpecialDirs then load
the config that may modify SpecialDirs).
Option 2 is even worse as it exposes implementation details to the type
and makes OOP impossible (e.g. method accepting a `PackageManager`
need to be changed). Option 3 is the best compromise, as its main downside
is that it requires to create a new `Dub` type, however that is already
required due to the amount of configuration points that do IO
(loadConfig, determineDefaultCompiler, computePkgSuppliers).

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.

Make inheriting from Dub easier ...

This would make extending TestDub much easier by exposing the class fields,
the common initialization routine, and a configuration point.
It also allows us to move TestDub to another module.

Trivial: Use public interface, not field names, in unittest ...

This would make moving this unittest to another module easier.

Trivial: Rename computePkgSuppliers to makePackageSuppliers ...

This is consistent with the naming of other factory functions.