Spack: Spack should complain if entries in packages.yaml are virtual packages

[tgamblin]

We currently allow users to do this:

packages:
  blas:
    blas: /some/path
    buildable: False
  lapack:
    lapack: /some/path
    buildable: False

blas and lapack above are virtual dependencies, but they should be concrete implementations.

Spack should complain when this happens so that users don't spend a lot of time trying to debug this mistake.

On the other hand, it's pretty obvious what the _intent_ is when users do this. They want to do something like:

packages:
  all:
    providers:
      blas: <some-blas>
      lapack: <some-lapack>
  <some-blas>:
    <some-blas>@<some-version>: /some/path
    buildable: False
  <some-lapack>:
    <some-lapack>@<some-version>: /some/path
    buildable: False

The problem is we have no idea which implementation <some-lapack> and <some-blas> are just from looking at the syntax at top -- Spack would need to auto-detect the implementation at /some/path.

We should revisit this when we look at auto-detecting system packages as discussed in #2020.

[alalazo]

Can't we code a cli command to edit external packages in packages.yaml ? Something like:

spack external-package add <package> --path=<path>
spack external-package remove <package>
spack external-package list

Then going through the CLI it should be easy to intercept this kind of errors.

[adamjstewart]

@alalazo See #2507.