Tracker for Code Aster MSVC support

### Comment:

Here is a "live" summary of the ongoing/remaining tasks for successfully compiling and distributing Code Aster for windows MSVC.

As of today the number of passing tests for the sequential tests for MSVC Code Aster is
* ~~(04.06.2024) 45% passing~~
* ~~(16.06.2024) 79% passing~~
* (02.08.2024) 85% passing

The MSVC version is currently using LLVM Intel Fortran (IFX) to compile Code Aster and LLVM Flang/IFX to compile the various dependencies

# Code Aster

- [x] Need to find an alternative to symlinking dlls. Symlinking requires administator privileges on windows and will not work on cf.
- I have asked Mathieu about it on the official Code Aster issue https://gitlab.com/codeaster/src/-/issues/1#note_1929414100
- To me it seems like we either make a patch with a rewrite of the pybind11 module definitions into separate pyd's or we try to see if static linking and making copies fixes things. I dont have much experience with static linking, so this might take me some time to figure out.
- https://github.com/conda-forge/code-aster-feedstock/issues/66
- I managed to solve this by simply replacing the symlinks with code that loads the dll and returns the pybind11 module definition.
- [x] Ensure changes to source files are safe wrt. memory. Some tests are currently running into memory issues.
- Solved by enabling openmp in Mumps and use MKL64 (not MKL) as recommended by mkl link advisor AND ensured that the Intel compiler bin path is not added to PATH (did cause conflicts). Memory increase was due to the integer represnting number of available openmp threads was huge (should be only 1).
- [x] Make sure we're using the appropriate lapack, liblapack package variants together with mkl.
- We are currently using MKL together with blas/lapack/liblapack compiled against MKL. So far it's looking good.
- [x] Solve clobbering issue between intel-openmp and llvm-openmp. This will cause failure when llvm-openmp replaces the `libiomp5md.dll` from intel-openmp.
- I solved this temporarily by simply re-compiling `intel-fortran-rt` against intel-openmp instead of llvm-openmp. No longer conflicts
- [x] Solve intermittent issue with OpenMP returning a too high number for the number of threads (>1e6 threads) causing extreme spikes in memory usages
- I solved this by simply disabling openmp on windows.
- [ ] Pass majority of sequential tests (>90%)

# Dependencies

1. Build and compile HDF5 with Fortran enabled on cf.
LLVM Flang needs a fix:
* https://github.com/conda-forge/hdf5-feedstock/pull/217
* https://github.com/llvm/llvm-project/issues/89403
4. Compile libmed with Fortran enabled (and use "long long" MED int type) once HDF5 is compiled
5. Compile Medcoupling with updated libmed
6. Compile Metis with 64 bit integers
- [ ] We need to either create a separate cf package "metis-aster" or make a dedicated variant of such as `metis=5.1.0=*aster*`
7. Compile scotch with 64 bit integers
* https://github.com/conda-forge/scotch-feedstock/pull/82
- [ ] We need to either create a separate cf package "scotch-aster" or make a dedicated variant of such as `scotch=7.0.4=*aster*`
8. Compile mumps against scotch and metis and use 64 bit integers
* https://github.com/conda-forge/mumps-feedstock/pull/111
- [ ] We need to either create a separate cf package "mumps-aster" or make a dedicated variant of such as `mumps=5.6.2=*aster*`
- [ ] Compile and Link mumps against Metis and Scotch. I have managed to do that in https://github.com/Krande/condapackaging/tree/main/src/code_aster/mumps by relying on the scivision repo for mumps

The issue names no source files or specific test entry point; it is a broad tracker for Windows MSVC builds. Start by reviewing the unchecked dependency tasks and the linked HDF5, Scotch, and MUMPS issues or pull requests. Done means the required dependencies build with the stated integer and Fortran settings and more than 90% of the sequential tests pass.

Written by the indexing model from the issue text.