environment shell: fix spack load

[psychocoderHPC]

Fix spack load with extended packet specifications that include spaces.
Solved by using perfect parameter forwarding via temporary array.

To be consistent with the current used shell features in setup-env.sh this PR is not compatible with the dash shell (there are no arrays in dash). PR #4048 is adding dash compatibility. To be dash shell compatible the usage of the temporary array _sp_spec must be removed and "${_sp_spec[@]}" must be substituted with "$@".

example

$ spack install zlib
$ spack install zlib cppflags='-O3 -march=native'
$ spack install zlib cppflags='-O2 -march=native'

$ spack find -d -L -f zlib
==> 3 installed packages.
-- linux-linuxmint18-x86_64 / gcc@5.4.0 -------------------------
k5hg4kkxiutkfl6n53ogz5wnlbdrsdtf    zlib@1.2.11%gcc

mse2fyzdxciszdhiqi4b5kl6fxkps3fh    zlib@1.2.11%gcc cppflags="-O2 -march=native"

vrnvj2fikcbxqxrymctnlpmud7wbuahk    zlib@1.2.11%gcc cppflags="-O3 -march=native"

$ spack load zlib cppflags='-O3 -march=native'
==> Error: Unexpected token
['zlib', 'cppflags=-O3', '-march=native']

[healther]

Does this still load all packages conforming to the asked for spec? I.e. you have two python installed and do a spack load python would it put both prefixes on your path?

[ax3l]

@healther sorry we don't get the exact question. can you please add an example? yes it still loads all matching. It's really just about passing the additional args properly to load.

(Btw, is the behavior of loading all matching specs a general bug of spack load? As a user I would expect to concretize the partial spec to the first matching and just load one.)

[tgamblin]

This LGTM, although I do agree with @healther that we should probably fix the "load all matching" behavior. That can be a separate PR, though.

[ax3l]

@healther @tgamblin yes, fully agreed. I wasn't aware of this behavior until now but it's super confusing. Imho, spack load should concretizise the same way as spack install does - to one package.