Prune the result of `Package.getAllDependenciesRange`

Move Package.findPackageFile to PackageManager, mock ...

Moving it to PackageManager allows us to call PackageManager.existsFile,
allowing us to mock a lot more things.

Use the proper constructor for PackageDependency ...

This code was using a deprecated constructor, but as it was in lambda,
it didn't trigger a deprecation message, however '-de' points us to
the issue.

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.

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

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

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.

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.

Change platform dependency to use a VersionRange ...

Note that this is a breaking change for library users.
It changes the platform dependency to only accept version ranges,
instead of any dependency. The end-users already could only write
VersionRange in there, the type was just too wide.

Deprecate unused packageInfoFilenames ...

This is of little value (it's just a map) and not used within dub.

Trivial: Simplify checkDubRequirements ...

Remove a redundant import and streamline control flow.

Add unittest to test collection of C sources and headers

fix typo(s)

Merge remote-tracking branch 'upstream/stable' into merge_stable

Fix typo in subpackage license warning

reduce dependency on the working directory ...

Improves library API usage and bugs with the build generator

Reduce dependency on `std.file` (#2547)

Use a central build cache for all build artifacts ...

Currently the central build cache is not configurable,
but as most build artifacts end up in `~/.dub/packages/` anyway,
this will be a positive change for users.

Move foreign code from global scope to dub.internal. ...

Avoids conflicting with the actual dub packages when working with dub as a library. Also, even if just by convention, it ensures that dependent code doesn't rely on this code as a public API.

Unify reading and writing files under a single API ...

This removes the range API and instead uses Appender,
while using a limited and centralized set of functions
to read/write from files.
The end goal is to permit dependency injection,
which is a pre-requisite to extending the test-suite.

Use configy library to parse dub.json file ...

This will provide a vastly superior UX to the users:
- They will be warned about typos;
- The type information provided will be more accurate and always include file/line infos
  (e.g. no more 'Invalid SemVer versions');
- We can expose a better recipe struct to library users on the long run,
  by separating the actual data DUB uses from what it reads;
- We can be more descriptive about errors / intent, for example by using `SetInfo`;

Remove 'unknown' version ...

It was never used.

Integrate `dependencyBuildSettings` into dependencies ...

Because those are specified in `dependencies`,
they should be stored alongside them.
Unfortunately this will slihtly increase memory usage in the common case,
but unlikely to a point where it would be problematic.

This is technically a breaking change as a field is getting removed,
however this struct has been manipulated a few times in breaking ways,
and it's unlikely `dependencyBuildSettings` is being used outside of dub,
given how recent it is and how narrow its usage is.
However, as `dependencies` is likely to be widely used, a compatibility
type and an `alias this` are provided not to break client code.

reduce FS access count for main file generation ...

as all the sourcePaths are checked and the last one is used, we just go
through all the sourcePaths in reverse and break when the first one is
found.

only do main file searching when neccessary

Keep logging functionality out of the public API as requested in https://github.com/dlang/dub/pull/2124#issuecomment-813016939.

New logging module - initial functionality ...

The new module replaces dub.internal.vibecompat.core.log by using the
same function names, but implementing colored output and the left
fixed-width tag. Overloaded functions are provided to output colored
text.

Still missing initLogging() and non-TTY stdout/stderr detection

Add support for coverage at compile-time (CTFE)

Implement injection of source files from dependencies into parent final binaries (executed/shared libraries)

fix CLI --print-builds implementation

fix Issue 1645: the DFLAGS env variable is not handled when --build is passed