Build with -preview=in ...

This reduces the number of deprecations issued in dub.

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.

Add betterC probing for performance and for applications without drun… (#2753) ...

* Add betterC probing for performance and for applications without druntime
* Build probe pragmas using a pragmaGen function rather than string duplication.
* Add some formatting adjustments

Trivial: Document and improve Dub.runCustomInitialization

Revert "Move data part of dub.platform to dub.data" ...

This reverts commit a0d80e8.
The approach might be wrong headed and will be reverted until
a more comprehensive diff can be submitted.

fetch: Support multiple arguments, projects, recursive fetch ...

Dub fetch was overly limited for no reason: Since we migrated from
`--version` to `name@version`, there is no reason to only allow one
argument, multiple packages can be fetched. Additionally, it could
be useful to fetch a package's dependency without building it,
which the command now supports.

Provide a consistent experience when interacting with dub fetch ...

'dub fetch doesNotExists' and 'dub fetch doesNotExists@1.0.0'
were behaving differently, both when they succeeded and when
they failed. Making them consistent was just a matter of deleting
a few lines of code, allowing us to also remove a branch.

Fix #2706: Dub run ignores locally registered packages ...

The code was overly complicated and failed to do what it intended.
If a version was provided, it would always call 'fetch' even though
getBestPackage would have returned something.
Assuming that sub-packages are always present is also not working,
as the following would fail:
$ rm -rf ~/.dub/packages/vibe-d && dub run vibe-d:data
    Warning Package 'vibe-d:data' was neither found locally nor online.
The new code is both shorter and simpler, taking advantage
of the various improvements made to the APIs over the year
(for example, getBestPackage with VersionRange.Any does the right thing).

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.

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.