Make interpolation code accessible to automatic differentiation

[Da-Be-Ru]

Here are the proposed changes we've coordinated so far, @chmerdon, @pjaap.

The gist of it:

• PointEvaluator gets an additional type parameter TCoeff for the entry type of the solution
• the different interpolators' evaluate! functions do an a priori check for the eltype of the target to match the result's eltype so the sparsity detection types etc. from the AD evals can run through
• the new function compute_interpolation_jacobian now computes the jacobian for a lazy_interpolate! call between a source_space and a target_space
• @pjaap and I put off the idea of passing a target entry type through the init_interpolator! calls from the element codes to the NodalInterpolator, MomentInterpolator, FunctionalInterpolator because this would necessitate a change to the FESpace.interpolators dictionary: now the AssemblyType wouldn't uniquely identify an interpolator anymore and it seemed weird making interpolators depend on the type of their evaluation (though I'm personally agnostic to that)
• I included a new set of tests for this: checking the interpolation matrix from a coarser to a finer grid as well as pairs of different FETypes on the same grid
• found some typos on the way and included your changes to the HCurl interpolations, @chmerdon

Things left to do:

• somehow we found that the new tests run through smoothly for all cases except the HCurl elements; still needs a fix
• haven't looked deeply into why, but the resulting interpolation jacobians are not fully sparse (e.g. the H1P1 into RT0 one contains zero entries in nzval)
• somehow we noticed that setting use_cellparents = true actually has the effect of slowing down the jacobian computation which we should probably look into

[chmerdon]

Concerning the HCURLN1 interpolation, I found that if one increases the quadrature order in the normal interpolation tests (test_interpolators.jl:112) by one, then already there the HCURLN1 interpolation fails (and not other FE). That is interesting and indicates that the element itself is buggy. It is not caused by your interpolation matrix code.

[chmerdon]

I think I have found the problem, please change the following in hcurl_n1.jl:

• remove the return in line 60
• add the line
  interior_dofs_offset(::Type{<:ON_CELLS}, ::Type{<:HCURLN1{2}}, ::Type{<:Triangle2D}) = 6

[Da-Be-Ru]

This doesn't seem to do anything on my end. Incorporating those changes fails the tests for me before and after with the same errors and numerical values.

EDIT: worked after all, was just doing it wrong :)

[Da-Be-Ru]

Chasing the last point on the list prompted #54 and #55 which could be taken care of at a later point.

As far as I am concerned, this PR could actually be merged into main if everyone's happy with the changes, so it would be nice if someone else has a final look over.

[pjaap]

Great work, I am happy with this

[pjaap]

Final thoughts from @chmerdon?

[chmerdon]

Yes, let's merge. Thanks!