doesn't save a ton of time: mvapich2 takes much longer, but it's not a
package we need to build on cooley

- build and run against mvapich with verbs support
- use newer gcc
- don't do dirty builds

- no longer any need for fork of spack (PR merged)
- no longer any need for @develop libfabric

- back out a recent opa-psm2 change
- updated packages.yaml reuqires a specific compiler

- not completely working yet, but seems to be close

- check separately for requirements for the pmdk, margo, and bake benchmarks
- compile whichever ones are compatible with the environment
- this is meant to make it easier to run certain benchmarks in
  incomplete environments

- fastest config is 4 rpc handler threads, pipelining, on socket 2

Looks like if we set SPACK_ROOT in this script we can isolate spack from
our onw environment

policy change:  by tracking @develop versions, we can catch any
incompatiblilites or performance regressions sooner.  It does mean we
are not regression-testing a released stack, so perhaps we should run a
weekly/monthly integeration check against fixed versions?

- was accidentally loading personal spack env on bebop jobs

- update to newer mpich
- find new compilers automatically, and display them
- force use of gcc 7.x

- likely will tweak arguments later

- current one doesn't seem to build on Bebop for some reason

- was launching worker threads on main pool instead of explicitly
created pool with multiple ES's

- also update yaml to build fewer spack packages

- also rename some scripts and email headings for consistency