Let unittest use PackageManager.store ...

No need to mock, all filesystem functions have been mocked
by the PackageManager now.

Mock IO in writeLocalPackageList / writeOverrides ...

Mocking IO is required for writeLocalPackageList,
as we want to test the 'add-path' behavior.
While it is not a big concern for overrides, as they
are deprecated and we are unlikely to add new tests,
it is easy to do, and already done for reading them.

Remove the need to mock PackageManager.refresh() ...

We can finally test the full features of the base function,
as we are now mocking the IO, not the logic.

Remove direct IO from Location.scanLocalPackages ...

This is one more step towards removing our mocking of refresh_.

PackageManager: Mock readText, do not mock load ...

This allows us to test the behavior of the base class much better,
by overriding the last IO function, readText.

Move Package.findPackageFile to PackageManager, mock ...

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

Remove the need for intermediate `.zip` file in PackageSupplier ...

By using a different overload of `retryDownload`,
we return the data instead of writing to disk,
ensuring that we don't have a lingering file
in memory and reducing IO.

This follow the same approach for deprecations as previous
`PackageSupplier` deprecations: it's an inevitable, but
easily fixable, breaking change for classes that implement
`PackageSupplier`, but it's a proper deprecation for client
code, based on the assumption that all the classes implementing
`PackageSupplier` are in Dub.

Test: Directly mock writeFile/existsFile from PackageManager ...

This allows us to reduce the number of functions we override,
as we would like to test writeSelections and refresh directly,
not the copy of them we have.

Merge pull request #2866 from Geod24/mlang/Simplify1 ...

Trivial: Simplify PackageManager's loadInternal

Move writing selections file to PackageManager ...

The PackageManager is the main source of IO in Dub,
and having it take responsibility for writing the
selections file reduces the number of special casing
we need to make when doing dependency injection.

Simplify condition.

Trivial: Simplify PackageManager's loadInternal

Properly fix issue #2691 by reverting to the original scanning behavior. ...

Reverts to the scanning/warning behavior that was in place before the warnings for the new package directory structure were implemented.

Revert "Fix #2691: Use same structure for managed and unmanaged path" ...

This reverts commit 1a53049.

PackageManager: Move addPackages inside loadGitPackage ...

This avoids calling addPackages when the package is already loaded,
and will allow us to handle PlacementLocation correctly in the future.

Allow better dependency injection on PackageManager's SCM operation ...

What we really want to override is the git clone operation,
so one way to approach this is to decouple it from the rest
of the code, then when our virtual filesystem is complete,
we will only need to override that one function.

Trivial: Slightly simplify PackageManager.store

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

Do not allow for removal of subpackages ...

Because it can mess up the system quite dramatically.

Improve unittest framework to have a virtual FS ...

This gets the unittest framework closer to the actual behavior,
and allows us to mock basic FS operations such as mkdir and writeFile.
Further improvements can be made to support more operations,
and to have package setup done before `TestDub` instantiation.

Adapt PackageManager.get[Best]Package to PackageName API ...

This paves the way to be able to automatically return subpackages.

Adapt loadSCMPackage to PackageName API

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.

Trivial: Align PackageManager's lookup signatures

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.

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.

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.

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.