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 dub.recipe.json to PackageName API

Adapt dub.recipe.sdl to PackageName API

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