Long CI is mostly due to examples with hard-coded patches: An easy fix

[sbryngelson]

Running ./mfc.sh test on a fresh clone of MFC will take forever. This is because it builds a version of simulation (the most time-costly compilation) for every example case that uses an analytical patch or hardcoded patch. This can be readily seen upon executing the above command. Below is a short excerpt from such a run:

 Generating case.fpp.
   * Codegen: patch_icpp(2)%pres = 101325*(1 - 0.5*(1.4 - 1)*(0.1 / 0.3)**2*exp(0.5*(1 - sqrt(x**2 + y**2))))**(1.4 / (1.4 - 1))
   * Codegen: patch_icpp(2)%alpha_rho(1) = 1*(1 - 0.5*(1.4 - 1)*(0.1 / 0.3)**2*exp(0.5*(1 - sqrt(x**2 + y**2))))**(1 / (1.4 - 1))
   * Codegen: patch_icpp(2)%vel(1) = 112.99092883944267*(1 - (0.1 / 0.3))*y*exp(0.5*(1 - sqrt(x**2 + y**2)))
   * Codegen: patch_icpp(2)%vel(2) = 112.99092883944267*((0.1 / 0.3))*x*exp(0.5*(1 - sqrt(x**2 + y**2)))
   Writing a (new) custom case.fpp file.
 $ cmake --build /storage/scratch1/6/sbryngelson3/MFC/build/staging/929859bdb4 --target pre_process --parallel 20 --config Release

By doing this codegen, a new build is required. We repeat this ~10 times or so.

So far as I can tell, there is an easy fix for this. These analytic patches can just be added as a hardcoded_ic in the source's include directory. There are three such files, one for each of 1D, 2D, 3D.

This part may take a little bit of work to translate from an analytic function in the case.py file to the hardcoded patch file, but it's not so bad because, as one sees above, the build process tells you exactly what the patch should look like!

In doing this, one would then have the example case.py call that "hardcoded" initial condition patch. There is documentation on how to do this in the MFC docs.

Once this is done, MFC will run ./mfc.sh test much more quickly. Perhaps 50-75% less time required. This saves everyone some pain.