Trivial: Pass a PackageName to loadSCMPackage

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.

Improve Dub.fetch API ...

The API was not ideal, as it meant the caller has
to be a bit repetitive in what it was doing:
- defaultPlacementLocation should be used when possible;
- A library user would most likely want FetchOptions.none;
- The most simple use case would be 'dub.fetch(pkgName)',
  meaning get me the latest version of pkgName, as is used
  by the tools fetching code;
All of this is now supported, in addition to a transition
to using the PackageName API.

Adapt SelectedVersions to PackageName API ...

Adapting to the PackageName API meant relaxing the input
a SelectedVersion method can accept, as we now handle
the subpackage part gracefully (ignoring it), instead
of potentially running into issue.

Simplify DependencyResolver.getRawPackage ...

Remove an extra variable and use early returns.

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.

Trivial: Replace redundant variable rootpack ...

There was already a 'basename' defined at the start
of the function, hence there is no need to reinvent
the wheel by doing a manual split.

Trivial: Silence buggy deprecation ...

Deprecation was:
```
std/algorithm/iteration.d(475,42): Deprecation: function `dub.dub.getRegistryPackageSupplier` is deprecated - This function wasn't intended for public use - open an issue with Dub if you need it
source/dub/dub.d(68,57):        instantiated from here: `map!(immutable(string)[])`
std/algorithm/iteration.d(582,19): Deprecation: function `dub.dub.getRegistryPackageSupplier` is deprecated - This function wasn't intended for public use - open an issue with Dub if you need it
std/algorithm/iteration.d(479,16):        instantiated from here: `MapResult!(getRegistryPackageSupplier, immutable(string)[])`
source/dub/dub.d(68,57):        instantiated from here: `map!(immutable(string)[])`
std/algorithm/iteration.d(594,23): Deprecation: function `dub.dub.getRegistryPackageSupplier` is deprecated - This function wasn't intended for public use - open an issue with Dub if you need it
std/algorithm/iteration.d(479,16):        instantiated from here: `MapResult!(getRegistryPackageSupplier, immutable(string)[])`
source/dub/dub.d(68,57):        instantiated from here: `map!(immutable(string)[])`
```
Triggers with LDC v1.36 as of 2024-01-10.

Deprecate system flag for registration, use cache instead ...

The system flag likely predates the global 'cache' option.
Logic dictates that 'dub add-path --cache=system' should behave
the same as 'dub add-path --system' but that is not the case.
However the PackageManager already has the right API in place,
so it is just a matter of deprecating the layers in front.

Trivial: Document and improve Dub.runCustomInitialization

Deprecate Package JSON constructor ...

Over the last year, various JSON overloads have been deprecated,
leaving space for more typed interfaces.
This Package constructor had resisted for long,
as the PackageSupplier interface returns JSON itself.
While changing it would be a breaking change and is not
currently possible, we can at least hoist the parsing one level.

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.

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.

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.

Trivial: Shorten a few parameter names ...

The parameter names were repeating the type name,
which in a language like D does not make sense.

Trivial: Make `TestDub` non-final ...

There is no reason to limit inheritance on this class.

Allow to load dub.selections.json before Project instantiation ...

The aim of this commit is to have at least one constructor
for Project that does not perform IO. By moving the IO to the
`Dub` class, we can keep the dependency injection in `Dub`
and `PackageManager` only, and don't have to specialize `Project`.

Trivial: Remove a dependency to std.path ...

Use the Dub versions instead.

Trivial: Merge two related unittest in dub package ...

They both test computePackageSuppliers in the end.

Refactor loadConfig to not rely on class state ...

By making it take a parameter and return a value, we make it
more obvious what is being used and changed, and we document
that rootPath is the only class member being read,
which is a fair assumption for any method of Dub.

Trivial: Move TestDub behind a version (unittest) ...

As it should not be compiled in the final binary for releases,
it's just a class to help with unittests.

Dub: Make determineDefaultCompiler configurable ...

By making it an idempotent (albeit not pure) function,
we allow other classes to override it with their own logic.
One such example would be returning an hardcoded path every time.

Trivial: Simplify some deprecated code ...

While this code is deprecated, it is confusing as it is
using findPackageFile only to provide a worse error message
than one would have got by simply calling Package.load.

Change PackageSupplier interface to accept VersionRange ...

This is a leftover of the time when everything in dub accepted Dependency.
While the mess had been untangled, doing so on this interface proved harder,
as there is no good way to deprecate it in a fully backward-compatible manner
without introducing a lot of overhead (a new type). Instead, this uses
a middle ground approach, where the external implementers (which most likely
do not exists) would break (although the fix is trivial), but callers would not.

Move application code for static ctor in main module ...

This code could easily mess with library users as it has
some side effects, so move it somewhere it will only affect
the binary.