[WIP] Chaining shared Spack

[scheibelp]

(This is very preliminary and I don't recommend even trying to use this at this point, but it covers some of the most essential changes that need to be made)

Changes which allow for a single system-installed Spack, with an installation root maintained by a system admin and an installation root maintained by a user (but for example admins can set config values that apply to any user of the Spack instance). Overall this is intended to allow admins to deploy an instance of Spack which looks like any other system-installed tool.

This includes:

• Move module roots to install tree root (not strictly required but in general for users they need to be located outside the Spack prefix)
  • This means that users no longer have to specify upstream module roots as shown in https://spack.readthedocs.io/en/v0.14.1/chain.html
• Add config scope associated with the install tree itself (this allows admins to assign specific permissions to the packages installed that are meant to be available to all users)
• (5/20/20) Environments are stored in the install root. This allows users with a shared Spack instance to make their own environments. This does not allow admins of the shared Spack instance to provide environments (that could be handled in a later PR)
• (5/20/20) For now it is assumed that users would not need to manage their own GPG keys: they would use the admin-created/added keys to sign new binary caches or to install them.

TODOs:

• Testing
• Move download cache to ~ (users can't store cached archives in the Spack prefix)

Non-essential TODOs:

• It came up that indices (e.g. the provider cache) should be instanced on a per-install-tree basis, that is important for correctness in general but is not essential to this PR
• If users of shared Spack could access the download cache used by the admins, this would reduce downloads and space used across all users of the shared Spack instance. For now, admins can create mirrors and add them to the config that users see.

See also: #11871

[scheibelp]

Add config scope associated with the install tree itself (this allows admins to assign specific permissions to the packages installed that are meant to be available to all users)

In more detail:

• There is a config scope associated with the install tree
• If the user runs spack --install-tree=X and X appears in config:shared_install_trees, the user config scope (i.e. from ~/.spack) is ignored and the installation-tree config scope is loaded
• If the user runs spack --install-tree=Y and Y is not a shared install tree (i.e. not in config:shared_install_trees), then the user config scope is loaded along with the installation tree config scope (in that order, with values from the install tree overriding values from ~)
  • Because of this ordering, the user can configure install trees in ~