Update hypre, MFEM, PETSC, and SELPc

[Sbozzolo]

The tagged commit for hypre is incompatible with CUDA 13, so that Palace does not compile with the latest version of the CUDA toolkit.

This commit updates a few packages to their latest versions and adds a new dependency on Umpire. Umpire is strongly recommended for hypre 3 with CUDA. I also switch to using CMake instead of autotools in hypre and not use the internal hypre device manager.

Similar to magma, umpire is automatically added to the build when buidling with CUDA or HIP.

Closes #498
Spack build in docs depends on spack/spack-packages#1855 (or on pushing the package.py to spack-packages)

[cameronrutherford]

Minor feedback. Overall great! 🥳

[victorapm]

Hi all, sorry for chiming in! Just wanted to note that hypre is moving to CMake as its recommended build system starting from hypre 3. Currently, hypre's CMake supports all build options that autotools' configure does and a few more. Build times is also generally faster with hypre's CMake

[Sbozzolo]

I did more extensive testing of this PR and found that my previous implementation broke shared builds. This is due to a transitive dependency (blt) using a deprecated way to link against the CUDA runtime. I found easiest to just cherry-pick hypre-space/hypre#1380, which implements a fix for this and has already been approved. If the PR is merged soon, we can just bump the git tag for hypre.

Some followup work that will be left is:

• The BLT patch I added to umpire has been merged upstream, but BLT is included as submodule of umpire with a specific git hash, so that the patch is not in umpire upstream yet. When umpire upgrades their BLT, we can remove the patch
• There seems to be a performance regression with saving to Paraview from GPU. I will open a more detailed issue on this later.
• Test-libceed crashes when Palace is compiled with CUDA (even when it is run on CPU)
• Palace uses HYPRE_Int hypre_CSRMatrixInitialize, but there seems to be a v2 for that function (https://github.com/hypre-space/hypre/blob/fca98afcd78a26b784dc24b0c3edb0e6140598af/src/seq_mv/seq_mv.h#L434)

[Sbozzolo]

Test-libceed crashes when Palace is compiled with CUDA (even when it is run on CPU)

I looked a little bit into this. I found that the crash occurs at

mfem::forall(m + 1, [=] MFEM_HOST_DEVICE(int i) { d_I[i] = d_I_old[i]; });

in fem/libceed/operator.cpp. The pointers seem valid at that point, so I am not entirely sure what's up.