VersionRange: Always output minor version for ~> and ^ ...

Dub was correct in outputting only the major version,
however this can lead to some confusion for users
as pointed out in #2830. Accepting ~>5 but only exposing
two states (~>5.0 and ~>5.0.0) will hopefully make
things a bit more obvious.

Fix #2901: VersionRange.toString() doesn't handle >0.0.0 ...

The `VersionRange.toString` method was not ideal and dropping
this rare case. A tiny improvement that was also done in the
process is to give higher priority to `matchesAny` so that
we get a more user-friendly output, given how common it is
(e.g. for `ToolchainRequirement`).

Prune the result of `Package.getAllDependenciesRange`

Make 'Dependency.init' invalid and align Any/Invalid property ...

VersionRange has Invalid and Any while Dependency has invalid and any.
One has to go, and it's going to be Dependency's.
In addition, make sure that the 'init' state of Dependency is a known state.

Add opEquals/opCmp to PackageName

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.

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.

Trivial: Remove dead imports from dub.dependency ...

This module is not performing any IO besides logging,
and doesn't use package_ or utils.

Remove logging from dub.dependency ...

The logging was not really useful: One unittest one,
and a spurious one with no action.
There is a lot of value in having dependency be data-only,
not having side effect or much dependency to the rest of dub.

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

fix path dependencies forgetting default/optional

fix typo(s)

Fix various DDOC warnings

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.

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

Fix #1752: Use 'no' as string representation of Dependency.Invalid

sumtype: Work around bugs in return type inference

Do not use Phobos' sumtype, use dyaml's versioned one ...

So that we can compile with older versions of the frontend,
currently v2.097 instead of v2.098.

Trivial: Remove redundant comparison ...

optional and default_ are indeed checked by opEquals.

Trivial: Correct code to use match's value instead of property ...

This code was accidentally working as it was calling the path property,
essentially entering another match on the SumType.

Remove 'unknown' version ...

It was never used.

Dependency: Deprecate path/repository setters ...

There is no real use case for changing a dependency in place,
instead we better let the user overwrite the dependency itself.

Trivial: Expand body of Dependency.opEquals ...

While the m_value difference is the common case,
the other ones need to be checked as well,
so put them first as they are cheaper.
Additionally, having three expressions on a single
return is not ideal for coverage / break,
so split it into 3 lines.

Dependency: Make VersionRange.match scope

Dependency: Take advantage of -preview=in ...

Since -preview=in is now used by dub for Configy,
we might as well take advantage of it here too.

improve some output coloring ...

See #2347

Deprecate Dependency.versionSpec ...

All places which assumed that Dependency contained a VersionRange have been culled,
so we can now start removing those properties.

Trivial: Move relevant documentation from Dependency.versionSpec to VersionRange

Dependency: Expose `visit` to `match` on `SumType` ...

To do so, we need to expose `VersionRange`.
The function is a free function as it otherwise triggers
a deprecation for dual contexts due to the template parameters.

Add some const qualifiers to Repository