Modularize interpolation testing

[KnutAM]

This PR includes some modularization of the testing of interpolations started in #798, and is the first breakout from that PR.

Specifically all tests that every base interpolations should pass should be put into test_interpolation_properties(ip::Interpolation). Having such a function was very valuable when developing the interpolations in #798, and it also makes it easier to include it in testing of such exotic interpolations when all assumptions currently tested for scalar and nodal interpolations don't hold.

It also separates testing of the reference shapes from the testing of the interpolations, and fixes one discovered issue with the thrown error from reference_shape_value(ip::DiscontinuousLagrange{shape, 0}, ... (it silently accepted i > n_basefunctions)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.59%. Comparing base (a5d0073) to head (dc669f6).
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1136   +/-   ##
=======================================
  Coverage   93.59%   93.59%           
=======================================
  Files          39       39           
  Lines        6087     6087           
=======================================
  Hits         5697     5697           
  Misses        390      390           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[termi-official]

Other than some minor detail this is fine for me. This should also make it easier in the future to extend the tests with interpolations having more fancy properties to check for.

[termi-official]

Stuff for a separate PR, but wouldn't it make sense to provide these via Ferrite directly instead of just in the tests? I think they can also be helpful in FerriteViz later to visualize H(div) vector-valued basis functions directly.

[KnutAM]

Not sure why you would need these for visualization? In principle I agree that some of these could belong in the code base, if nothing else to allow automatically plotting the reference shapes for documentation.

If it is only for testing purposes, but also useful for downstream testing, I think it at least should be put in a submodule to separate the namespace and make it clear that it isn't used by Ferrite itself. For example #1135 is an example of code I find quite confusing that we have (but that's not even used in testing, so can probably be removed). I guess if we want to move test util code into src is a question for @fredrikekre?

Regarding the implementations herein, I think we should also attribute more implementation to the reference shapes themselves (as I did here for the normals), and not to an interpolation on the reference shape. I always find it a bit strange that we don't have reference_coordinates(::Type{AbstractRefShape}), but of course, these coordinates are rarely used.

I also noticed now that reference_face_area here should be updated to use facet instead of face, but that's also for a separate PR.

[termi-official]

Not sure why you would need these for visualization?

With this stuff it is easier to show (and visually debugging) normal mappings.

I think we should also attribute more implementation to the reference shapes [...]

Totally agree. For me Ferrite is a toolbox and should provide all basic tools to build more complex finite element codes on top.