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.

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

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.

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

Fix #2696: Segfault with bad dub.sdl ...

This was a null pointer being passed down.
However, while looking at the code, it was obvious that similar
bugs would trigger for subpackages (as the code was not handling
`null` packages either), so test cases for those have been added.

Add unittest framework and some dependency tests ...

Dub has always been notoriously hard to test due to the amount of IO it does.
Over the past few years, I have progressively refactored it to allow
dependency injection to take place, which this finally put into action.
By overriding the `PackageManager`, `PackageSupplier`, and a few strategic
functions, we can start to unittest Dub's behavior solely in unittests.
This should hopefully tremendously helps with adding regression tests
for the package manager side of Dub (the build side still need work
to have similar capabilities).

Allow to load dub.selections.json before Project instantiation ...

The aim of this commit is to have at least one constructor
for Project that does not perform IO. By moving the IO to the
`Dub` class, we can keep the dependency injection in `Dub`
and `PackageManager` only, and don't have to specialize `Project`.

add `dub describe --data=configs,builds` ...

supersedes the trivial part of #2204

fix typo in cImportPaths dub describe data ...

since it's not used anywhere else in code in this casing, adjusted to
make it the same as everyhing else. Was likely a bug, but no issue was
filed for this yet.

Test cases don't seem to exist for cImportPaths with dub describe at all

Add unittest to test collection of C sources and headers

Make getDUBExePath returns a NativePath

improve warning messages, especially with ~branch (#2585) ...

* improve warning messages, especially with ~branch

* fix single package

Add betterC support - fixes #1636 (#2581) ...

Co-authored-by: Etienne Cimon <etcimon@gmail.com>
Co-authored-by: WebFreak001 <gh@webfreak.org>

fix typo(s)

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

reduce dependency on the working directory ...

Improves library API usage and bugs with the build generator

Fix various DDOC warnings

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.

Replace all instances of mkdirRecurse with ensureDir ...

All usages actually want to ensure the directory is present,
and don't care about having a separation between existence check
and creation.

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.

Make the test runner code more readable ...

Using manifest constant and a single format call,
the code will be more readable than piecemeal additions.

PackageManager: Load packages lazily on dub build ...

A problem of the current design of dub is that all locations are scanned,
regardless of what action is being performed, often multiple times.
With this change, a regular `dub build` on a project with all dependencies
resolved will no longer loads all available package, which can substantially
speed up development.

Use getPackage instead of getBestPackage for resolved dependencies ...

getBestPackage is intended to find the highest local version matching a range.
Due to this, it has to eagerly load packages and iterate through them.
However, when loading a resolved dependency, we have an exact Version,
which is simply wrapped in a VersionRange, so we can call getPackage instead.

Deprecate `PackageManager.refresh(true)`, only expose `refresh()` ...

It is not actually used, as all call sites but two use false as an argument.
The two calls using true are inside a constructor, meaning there will be no
pre-existing packages, so whether true or false is passed will have
the same effect / result.

Project: Only print warning about mismatching dependency specs for versions ...

When using path-based dependency or repository dependencies,
we shouldn't need to validate those as they always match.

Fix #2450 - issue1474 testcase is broken on Windows

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`;