the 'modules' commands won't show us what we are looking for now that
spack does all that itself.

yes this is the same as the bebop fix from a few weeks ago. sigh.

I don't know if 100 iterations is enough to give us confidnece in the
numbers, but I had to crank the latency test way way down to get this
test to complete in a reasonable amount of time.

- file backend could have different dependencies

- may need some tweaks to confirm/correct which interface is used

- must build benchmarks twice, once with pmdk back end and once with
  file backend
- rpath in executable keeps a fixed library linkage otherwise

- includes two bake builds: one with pmdk, one with file backend
- actual runs do not work yet due to a mount problem

- set $HOME to avoid perturbing ~/ config files for the user running this script
- remove deprecated --dirty and LD_PRELOAD hacks
- remove explicit set of SPACK_ROOT in favor of variable set by spack itself
- other misc streamlining improvements

- this is a workaround to strip unusual characters out of output so that
  the mailx command will put it inline with message

idiomatic spack sets SPACK_ROOT and sources env based on that

Whoops: while I was here, build ior-mobject which will pull in just
about every one of our SDS packages

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

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