Proposal: Split interpolation implementations into separate files

[gijswl]

While working on the Nedelec and RT interpolations, I found it was quite difficult to move around the large interpolations.jl file (it being approx. 2000 lines). My proposal would be to put each interpolation family into its own file to improve maintainability.
Besides that, some interpolations were missing from the list of implemented interpolations. I've added these to the docstring of each family.

Thoughts?

[codecov]

Codecov Report

❌ Patch coverage is 97.95222% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.89%. Comparing base (0b130ef) to head (ba9bd67).
⚠️ Report is 56 commits behind head on master.

Files with missing lines	Patch %	Lines
src/Interpolations/Interpolations.jl	92.07%	13 Missing ⚠️
src/Interpolations/Lagrange.jl	99.44%	2 Missing ⚠️
src/Interpolations/CrouzeixRaviart.jl	96.66%	1 Missing ⚠️
src/Interpolations/RannacherTurek.jl	96.96%	1 Missing ⚠️
src/Interpolations/Serendipity.jl	98.24%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1189   +/-   ##
=======================================
  Coverage   93.89%   93.89%           
=======================================
  Files          39       48    +9     
  Lines        6436     6436           
=======================================
  Hits         6043     6043           
  Misses        393      393           

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[termi-official]

I also already thought about this, but was not sure what a good policy to group them could look like, as too fine granularity can also be problematic if the number of interpolation keeps growing.

The implemented ones were added to the abstract type to improve visibility to what is implemented already.

Also, should the resulting commit for this PR be ignored for history?

[KnutAM]

Split based on conformity could make sense. Ignore history would be good.

The implemented ones were added to the abstract type to improve visibility to what is implemented already.

I've had a thought to define a tuple/vector of implemented interpolations. That could automate testing, enable documenting which cases are implemented etc.

[gijswl]

I think it is most natural to split by FE space, as I proposed in the commit.
This is also the approach taken by Gridap and deal.ii.

Ignoring the commit for history seems like a good idea.

[KnutAM]

For me, that split could be alright too, but it will as Dennis says lead to many small files which is a bit inconsistent with how the rest of the repo is organized. Perhaps @fredrikekre has some opinion here?

[fredrikekre]

I don't mind the long file but this split is ok too.