packagesuppliers/filesystem.d: Only look for versions of package_id ...

When looking for versions of a package don't include any files that
aren't versions of the queried package.

If a directory contains the files botan-1.zip and botan-math-2.zip
the current implementation would report both 1 and math-2 as
candidates followed by an error that math-2 is not a valid version.

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

Simplify DependencyResolver.getRawPackage ...

Remove an extra variable and use early returns.

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.

Expand selections file handling to handle new versions ...

Up until now, the selections file has had a `fileVersion` in it,
but that number was always stuck to 1.
In order to make it possible to handle more than one version,
a bit of scaffolding needs to happen in the config parser.
This lays the ground for a version 2 of the selections file.

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.

Deprecate unused getSubPackagePath ...

While looking at the subpackage code, I was wondering
why more places didn't call getSubPackagePath instead
of getSubPackageName, and that is because subpackages
can only be one level deep.

Trivial: Deprecate string overload of readPackageRecipe ...

To be consistent with the rest of Dub, use NativePath.

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.

Configy: Synchronize with upstream ...

Bring in some documentation improvements and PR48 bugfix.

Allow building deprecated modules without deprecation warnings ...

The compiler issues a deprecation warning only on a
"non-deprecated" -> "deprecated" transition.  As such, building or
testing Dub packages which have deprecated modules when a
dub_test_root.d file needs to be generated will cause deprecation
warnings.

This in turn makes it impossible to use `buildRequirements
"disallowDeprecations"` in this situation.

Fix this by simply making the auto-generated root
module (dub_test_root) deprecated. As it is the compiler's entry
point, the module itself will not cause a deprecation warning, and it
importing deprecating modules will not cause deprecation warnings (as
there is no longer a transition of deprecation state).

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.

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.

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