This draft PR is a tentative implementation of the following iterative procedure to get separate concretization of build dependencies:

The basic idea is to decouple the problem and:

1. Solve first the link/run subDAG of the root specs, and keep track of their build requirements
2. Perform another solve unifying on every dependency type (like we do now) and concretize the build requirements
3. Compose the initial spec from the two solutions

Step two is performed as a single "build environment" concretized with unify: when_possible and can have different requirements from the specs concretized at step one. In this draft, for instance, we use the default compiler for build dependencies. This allow us to concretize:

$ spack graph -d --color py-shapely %oneapi

and obtain the following graph (build dependencies in red):

In case we have a conflict during the solve at 2 the idea is to go back at point one with additional integrity constraints, which would prevent the offending build requirements to be in a valid solution.

Additional notes:

• During step 1 we have to take particular care to concretize build dependencies for extensions (like py-setuptools) correctly. This is because those build dependencies need to share the same compiler etc. than the underlying interpreter. See py-setuptools for an example of that in the graph above
• The feedback cycle is not implemented here, so any conflict when computing build dependencies currently leads to a failure
• The algorithm can be extended to have more than one "build environment" levels. This fits cases like having to build an intermediate compiler when the system provides an ancient one and we want e.g. to bootstrap the latest.