CI: Reduce dependency on std.path / std.file in one unittest ...

This will make migrating to the abstracted IO much easier.

Look up `dub.selections.json` files in parent directories too (#2272) ...

* Look up `dub.selections.json` files in parent directories too

In case the root package directory doesn't contain a `dub.selections.json`
file, look in parent directories too and load the first (deepest) one.

This allows using a 'central' `dub.selections.json` file for a repository
containing multiple dub projects, making it automatically apply to all
builds in that source tree if located in the repository root directory
(unless a local `dub.selections.json` overrides it).

Such an 'inherited' selections file is never mutated when running dub for
a nested project, i.e., changes are always saved to a *local*
`dub.selections.json` file.

Tests: Implement the ability to mock the registry too ...

So far tests have limited themselves to the local state,
but we want to expand them to test the behavior of dub
when fetching packages, so we need a convenient way
to add packages to the registry.

Clear an unprinted deprecation during dub build ...

This deprecation is currently not printed by DMD,
but shows up if '-de' is used while compiling.
This solution is a workaround, as a proper fix
would mean not using the function in the first place,
but that requires a more in-depth rework.

Move the I/O part of Project.loadSelections to PackageManager ...

By doing so we can remove a sizeable amount of duplication as well
as the last `Dub.loadPackage` override. The resulting API is not
ideal, for example it doesn't allow to distinguish between parsing
errors and non-existent file, but will have to do for now.

Respect skipRegistry value from configuration files ...

Currently, the skipRegistry value in configuration files is ignored,
the final value is either the one the user passed on the command line,
which is the intended behavior, or the value `none` if the user didn't
pass a --skip-registry argument.

This commit fixes this by introducing the new value `default_` to the
SkippackageSuppliers enum to know when the user didn't pass the
skip-registry argument and the value should be taken from the
configuration files.

Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>

Remove abandoned registry mirrors. ...

Both of these have not been working for a long time now.

Remove the need for intermediate `.zip` file in PackageSupplier ...

By using a different overload of `retryDownload`,
we return the data instead of writing to disk,
ensuring that we don't have a lingering file
in memory and reducing IO.

This follow the same approach for deprecations as previous
`PackageSupplier` deprecations: it's an inevitable, but
easily fixable, breaking change for classes that implement
`PackageSupplier`, but it's a proper deprecation for client
code, based on the assumption that all the classes implementing
`PackageSupplier` are in Dub.

Merge both TestDub constructors ...

Those constructors had different but non-overlapping functionalities.
In the event one wanted to set one of the parameters passed to Dub
constructor but also initialize the FS, one was out of luck.

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

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

Adapt DependencyResolver to PackageName API

Trivial: Clean up temporary variable in Dub.fetch ...

And improve the message displayed to users.

Do not allow for removal of subpackages ...

Because it can mess up the system quite dramatically.

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

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

Adapt loadSCMPackage to PackageName API

Trivial: Add 'in' on a parameter

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.

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.

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.