Bug when satisfying vdeps with multiple providers

[tgamblin]

From @fpruvost:

I have some troubles since the last merge I've done with your develop branch at cf3d236 (3 days ago) state.
The find process which impact other features like uninstall seems buggy.
I reproduced my problem with your develop:

    $ spack install netlib-lapack ^netlib-blas
    $ spack install netlib-lapack ^openblas
    $ spack find    netlib-lapack ^openblas

spack returns both netlib-lapack^netlib-blas and netlib-lapack^openblas so that I cannot uninstall one of them.
If I rm -r the prefix path, the install is still referenced in the database so that I cannot use this method to uninstall this spec.

Do you have any idea of what is going wrong with the find process here?

---

Maybe this is related to virtual packages depending on another virtual package like lapack -> blas
because it seems I don't meet the problem with packages on top of blas which do not "provides" a virtual package.

[tgamblin]

This is fixed by 7383bd3:

Fixed bug #209: problem with satisfies() for virtual dependencies.

- _cross_provider_maps() had suffered some bit rot (map returned was
  ill-formed but still worked for cases with one vdep)

- ProviderIndex.satisfies() was only checking whether the result map
  was non-empty.  It should check whether all common vdeps are *in*
  the result map, as that indicates there is *some* way to satisfy
  *all* of them.  We were checking whether there was some way to
  satisfy *any one* of them, which is wrong.

- Above would cause a problem when there is more than one vdep provider.

- Added test that covers this case.

- Added `constrained()` method to Spec. Analogous to `normalized()`:
  `constrain():constrained() :: normalize():normalized()`