Trivial: Adapt fixPathDependency to PackageName API

Trivial: Align PackageManager's lookup signatures

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.

Let uesr $DFLAGS override build settings as much as possible ...

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

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.

test/use-c-sources: disable for gdc ...

Gdc doesn't support `#include`s in importC

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

dub.sdl: Use compiler specific `-preview=in`. Disable it for GDC. ...

Having `-preview=in` in dflags without a platform specification
leads to errors with gdc:
```
gdc: error: unrecognized command-line option ‘-preview=in’; did you mean ‘-fpreview=in’?
```

However, using the proper `-fpreview=in` for gdc causes an ICE:
```
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/d/std/math/exponential.d:587:30: internal compiler error: in layout_aggregate_type, at d/types.cc:562
  587 |             enum maxOdd = pow(2.0L, real.mant_dig) - 1.0L;
```

Leave `-preview=in` enabled for dmd and ldc and wait for a fix
before enabling it for gdc.

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

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

Upgrade dependencies

Build with -preview=in ...

This reduces the number of deprecations issued in dub.

Update supported compiler versions ...

This is to support using `-preview=in` and reducing
the amount of deprecations.

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.