Refactor filesystem abstraction to and use it in production ...

The filesystem abstraction needs to be known to production to avoid
too much code duplication. So far we have used functions in
`PackageManager` that the `TestPackageManager overrides.

With this change, we can remove them, and instead just pass an interface.
On the long run, we should be able to do dependency injection simply
by passing a different object (or overriding) the `Dub` class.

An initial attempt made `FSEntry` inherit from the `Filesystem` interface,
however that attempt was doomed as it conflates two different abstractions:
`FSEntry` is a "node" in the filesystem, which we want to act on in one
of multiple ways: move to another node, or take an action. On the other hand,
`Filesystem` is a more generic interface and takes a path as most of its
function's argument. A `path` and an `FSEntry` have a lot of overlap
(they are a reference to a node in a tree) and the resulting interface
would have been very clunky.

Look up `dub.selections.json` files in parent directories too (#2272) ...

* Look up `dub.selections.json` files in parent directories too

In case the root package directory doesn't contain a `dub.selections.json`
file, look in parent directories too and load the first (deepest) one.

This allows using a 'central' `dub.selections.json` file for a repository
containing multiple dub projects, making it automatically apply to all
builds in that source tree if located in the repository root directory
(unless a local `dub.selections.json` overrides it).

Such an 'inherited' selections file is never mutated when running dub for
a nested project, i.e., changes are always saved to a *local*
`dub.selections.json` file.