Binary crates, toolchain management and use (#775)

Binary crates, toolchain management and use (#775)

* Implement sha256 and hash use test (#765)

* Implement binary origins and their deployment

* `alr install` for shared installations

Essentially, we have a second location for dependencies at ${ALR_CONFIG}/cache.
In following PRs the releases therein will be available during dependency
resolution, to be reused.

`alr install` for manual crate installation

Installed crates are used by the solver

Autodiscover installed releases

Show differences due to changed install status

Install: implement release removal

* Toolchain configuration assistant

Menu for choosing among multiple options

Show actual compiler versions to the user

Install and remember the user choice

User_Input: Take a possible Ctrl-D into account

* Re-enable "provides" in index and use them in alr

New, more flexible provides type

WIP: going back to provides as list of deps

All but loading of "provides"

Loading of provides

Installed provides are used during solving

They're not yet used for regular dependencies

Display provider in the `alr with` variants

Prevent solving of conflicting dependencies

If two releases provide the same crate, they cannot be simultaneously in a
solution.

solver tweaks for provides + externals

Improvements to solution space by reusing releases

When adding a release to a solution, check whether other dependencies can be
satisfied by this same release. Not a big deal, could be disabled if too costly
in the future.

* Use toolchain in solve/build/environment

Insert explicit dependency on the configured gnat

Do not explicitly insert dependency on toolchain

Instead, we simply coerce when given a generic gnat dependency into the
configured one. This is less intrusive as the user does not see unexpected
dependencies on the compiler in the solution (unless explicitly requested).

Extra info in `alr install` list

Generalized assistant for all tools in toolchain

* Rename install command to toolchain

* Implement "provides" for external detectors

For now this is restricted to a single alternate crate name. By necessity, the
equivalence has to be to the same version, whereas provides for regular
releases are more general as they can rely on precise versions which are known
in advance.

* Tweaks for new GNAT crate names

* Solver: reuse known GNAT on generic gnat= dep

* Integrate external gnats in shared releases

This is logical because these are always available in all configurations. But
the important benefit is that the solver can use them in preference to a remote
native compiler.

* Documentation in doc/, `alr help`

* Fixed circularity, Config.Edit is now untangled

* Tweaks to pass existing tests

* Self-review fixes and clean-up

* New tests for toolchains and related features

* Windows-specific testsuite fixes

* Review fixes

In particular, the avoidance of downloading a compiler for a generic gnat
dependency. This is tested in testsuite/tests/solver/compiler-installed