Track multiple processes on Travis only for build tests

[alalazo]

On a local workstation, it seems that tracking multiple processes during coverage may result in malformed coverage reports for unit tests and not for build tests.

Given that multiple processes make a difference in coverage mainly for build tests, try to disable the tracking for unit tests to see if we get more stable coverage results.

[alalazo]

@tgamblin @adamjstewart To extend a bit the explanation on the logic of this PR.

Using --concurrency=multiprocessing serves the purpose of tracking the coverage of code executed in spawned processes. I noticed today, while debugging the sudden drops in coverage, that running:

$ coverage run bin/spack test

on my laptop was sometimes resulting in a couple of malformed files (over the hundreds that were produced by the command). These malformed files are, I think, what sometimes prevent Travis from generating a well formed .coverage report to submit to codecov.

I also noted that build tests, like:

$ coverage run bin/spack install mpich

apparently didn't suffer from the same problem. So, while it's not really correct from a theoretical point of view, I thought we could disable tracking child processes in unit tests - i.e. where it matters the least - in favor of more stability in coverage numbers.

At a first glance this works, as we have all the 10 expected reports uploaded to codecov. The price is a fictitious decrease in coverage for a few modules in llnl that are used in child processes.

TLDR If you think this is worth it, the PR is for me ready to be merged.

[adamjstewart]

Stability of coverage reports > lines of code covered

I'll merge this for now. Hopefully we can get to the bottom of why concurrency is a problem for the unit tests. If llnl is the only place where coverage drops, it should be easy to add unit tests for these functions.