This commit edits the Makefile to use github.com mirrors rather than the
default mirrors of the dependency packages installed by GO.

Environments are nowm by default, created with views.  When activated, if an environment includes a view, this view will be added to `PATH`, `CPATH`, and other shell variables to expose the Spack environment in the user's shell.

Example:

```
spack env create e1 #by default this will maintain a view in the directory Spack maintains for the env
spack env create e1 --with-view=/abs/path/to/anywhere
spack env create e1 --without-view
```

The `spack.yaml` manifest file now looks like this:

```
spack:
  specs:
  - python
  view: true #or false, or a string
```

These commands can be used to control the view configuration for the active environment, without hand-editing the `spack.yaml` file:

```
spack env view enable
spack env view envable /abs/path/to/anywhere
spack env view disable
```

Views are automatically updated when specs are installed to an environment. A view only maintains one copy of any package. An environment may refer to a package multiple times, in particular if it appears as a dependency. This PR establishes a prioritization for which environment specs are added to views: a spec has higher priority if it was concretized first. This does not necessarily exactly match the order in which specs were added, for example, given `X->Z` and `Y->Z'`:

```
spack env activate e1
spack add X
spack install Y # immediately concretizes and installs Y and Z'
spack install # concretizes X and Z
```

In this case `Z'` will be favored over `Z`. 

Specs in the environment must be concrete and installed to be added to the view, so there is another minor ordering effect: by default the view maintained for the environment ignores file conflicts between packages. If packages are not installed in order, and there are file conflicts, then the version chosen depends on the order.

Both ordering issues are avoided if `spack install`/`spack add` and `spack install <spec>` are not mixed.

Add documentation for the Spack chain feature added in #8772

* Fix bug when system perl is used.

If system perl is being used through packages.yaml there cannot be dependent modules.
The  setup_dependent_packages function should not do anything in that case.

* intel: consolidate libs() in the base class

* white space

* flake8

* openmpi: add 4.0.1

* openmpi: enable-mpi1-compatibility for 4.0.1 and above

* remove preferred

* make 3.1.3 preferred

Add patch for gfortran-8 runtime errors

Unset SPACK_INCLUDE_DIRS so the compiler wrapper does not prepend any -I flags. The assumption is that cmake will set the correct include flags. (#11129)

see https://github.com/spack/spack/pull/10943#issuecomment-475303870

When providing a track, the cdash reporter will format the stamp
itself, as it has always done, and register the build during the
package installation process.  When providing a stamp, it should
first be formatted as cdash expects, and then cdash will be sure
to report results to same build id which was registered manually
elsewhere.

* Update Spec.prefix to have special case for 'None' in database path; regression test
* Update in database reader rather than spec
* Change assertion to conditional + raise
* Added test for concrete check in Spec.prefix

* fixes py-basemap package
* remove basemap mpl_toolkit __init__.py

The module_parsing test checks whether the module function is available
by looking for the string 'not found'. If the user has set a different
locale, the test can assume that the module function is available when
it actually is not.

* miniamr: add develop version and update release

* change from url to git

* add url back