concretizer: reduce search space with static analysis (#48729)

Currently, when we setup the ASP problem for `clingo`, we don't take into account the configuration. This results in setting up ASP problems that are larger than necessary, with possibly redundant information, and higher concretization times. 

This PR tries to improve things by adding an opt-in feature that computes the _possible dependencies_ of a solve taking also into account the current configuration, and avoids adding possible dependencies that we are certain can't be in the final solution.

The feature can be activated with:
```yaml
concretizer:
  static_analysis: true
```

Examples of simple rules to discard dependencies are:
- Dependencies that are not buildable, and for which no binary is present (e.g. `cray-mpich` etc. on non Cray systems)
- Dependencies that are not for the current platform (e.g. `msmpi` on non Windows platforms)
- Conditional dependencies that cannot be activated, because of some user requirement (e.g. `cuda` etc. if the user requires `~cuda` in configuration)
- Virtual providers that cannot be used, because of a requirement on a virtual

The speed-up these rules seem to give depends on the use case at hand, but if the configuration is updated properly, they are noticeable. 

Since in cases where there is no rule to exclude packages upfront, reuse is active, and this option is activated, it's possible to see some minor slow down, the feature has been added as opt-in, so it's turned off by default.

share/spack/gitlab/cloud_pipelines/stacks/developer-tools-x86_64_v3-linux-gnu/spack.yaml

@@ -2,10 +2,16 @@ spack:
   view: false
   packages:
     all:
-      require: target=x86_64_v3
+      require:
+      - target=x86_64_v3
+      - ~cuda
+      - ~rocm
+
   concretizer:
     unify: true
     reuse: false
+    static_analysis: true
+
   definitions:
   - default_specs:
       # editors

share/spack/gitlab/cloud_pipelines/stacks/e4s/spack.yaml

@@ -4,16 +4,32 @@ spack:
   concretizer:
     reuse: false
     unify: false
+    static_analysis: true
 
   packages:
     all:
-      require: '%gcc target=x86_64_v3'
-      providers:
-        blas: [openblas]
-        mpi: [mpich]
+      require:
+      - '%gcc target=x86_64_v3'
       variants: +mpi
+    mpi:
+      require:
+      - mpich
+    blas:
+      require:
+      - openblas
+    lapack:
+      require:
+      - openblas
     binutils:
       variants: +ld +gold +headers +libiberty ~nls
+    cmake:
+      require:
+      - "~qtgui"
+      - '%gcc target=x86_64_v3'
+    gmake:
+      require:
+      - "~guile"
+      - '%gcc target=x86_64_v3'
     hdf5:
       variants: +fortran +hl +shared
     libfabric:
@@ -27,19 +43,25 @@ spack:
         +ifpack +ifpack2 +intrepid +intrepid2 +isorropia +kokkos +ml +minitensor +muelu
         +nox +piro +phalanx +rol +rythmos +sacado +stk +shards +shylu +stokhos +stratimikos
         +teko +tempus +tpetra +trilinoscouplings +zoltan +zoltan2 +superlu-dist gotype=long_long
-    mpi:
-      require: mpich
     mpich:
-      require: '~wrapperrpath ~hwloc target=x86_64_v3'
+      require:
+      - '~wrapperrpath ~hwloc'
+      - '%gcc target=x86_64_v3'
     tbb:
-      require: intel-tbb
+      require:
+      - intel-tbb
     vtk-m:
-      require: "+examples target=x86_64_v3"
+      require:
+      - "+examples"
+      - '%gcc target=x86_64_v3'
     visit:
-      require: "~gui target=x86_64_v3"
+      require:
+      - "~gui target=x86_64_v3"
     paraview:
       # Don't build GUI support or GLX rendering for HPC/container deployments
-      require: "+examples ~qt ^[virtuals=gl] osmesa target=x86_64_v3"
+      require:
+      - "+examples ~qt ^[virtuals=gl] osmesa target=x86_64_v3"
+      - '%gcc target=x86_64_v3'
 
   specs:
   # CPU