Feature/write-surface-stl

This output module for nekmesh takes the linear surface mesh and outputs it as a standard .stl surface triangulation format.
The stl is formatted in such a way that star-ccm can read the surface as an input and obey it when generating the 3d mesh.
This will form part of the NekMesh+star-ccm mesh generation pipeline

See merge request !668

Improve Homogeneous1D dealiasing efficiency

This MR optimizes the homogeneous dealiasing, mostly by eliminating many redundant Fourier transformations (42 regular and 12 padded per time step, if I am not mistaken...).

This also implements the case with both homogeneous and spectral/hp dealiasing.

See merge request !622

Feature/merge-surface-mesh

This merge fixes some ccmio code and adds a new module which can take the high-order information from a surface mesh and insert it into the current working mesh. This only works if the two linear surfaces match. They dont have to be the same Ids because ANN is used to find corresponding nodes.
This will be part of the MeshGen with starccm pipeline

See merge request !669

APE: Fix basefield handling

This MR introduces a continuous expansion for the APESolvers basefields. 

This fixes a bug where interpolated fields  cause the solver to diverge because currently, only discontinuities of the perturbation fields are handled in the rieman solvers.  Forcing the basefield to be continuous evades this problem, enables smoothing (in a future MR) and increases the overall stability.

This also means we have to go back to the constant c formulation which should not cause any issues since the old implementation was quite unstable anyway.

This also adds the ability to compute the CFL number to the APESolver and  adds the sourceterm to the fields written to fld files.

See merge request !664

fix/cmake-dependencies

With the creation of FieldUtils the dependencies of the libraries and utilities on each other and a little off. This fixes that.

The only major change is, because none of the utilities depend on solverutils anymore it has been made a function of NEKTAR_USE_SOLVERS. This is so that, for people like me, who don't compile the solvers, time isn't wasted compiling unnecessary libraries.

See merge request !671

Feature/boundary layer generation upgrade

This branch brings the first update to the Nekmesh mesh generation system.

The primary new feature is a complete overhaul of the boundary layer generation capability meaning boundary layers can be generated on much more complicated CAD than the convex only requirements of the old system.

It also adds new documentation to Nektar describing how to operate the mesh generator.

There is a modification to the nodal triangles in the reference elements to make the orderings consistent with what people believed nektar used. This will break some peoples meshes if they use NodalTriFekete or NodalTriElec curve face tags.

Regression tests have been added for the mesh generation.

Completed:
+ Boundary layer upgrade
+ Nodal triangle edit
+ Regression tests
+ Finish docs

See merge request !576

FilterFieldConvert

This MR will introduce a new filter, which will be able to run modules from FieldConvert on a checkpoint. This filter replaces FilterSampler, and therefore the new functionalities will extend to other filters derived from it (AverageFields, ReynoldsStresses). An example of the setup for that would be:
``` xml
<FILTER TYPE="FieldConvert">
    <PARAM NAME="OutputFile"> filename.vtu </PARAM>
    <PARAM NAME="OutputFrequency"> 100 </PARAM>
    <PARAM NAME="Modules"> vorticity homplane:planeid=4 </PARAM>
</FILTER>
```
It is unlikely that all options and modules will be supported. However, the main idea is to use this with modules that result in outputs with reduced size (e.g. isocontour, meanmode for 3DH1D). This way we can obtain these outputs more frequently than would be practical by storing the full checkpoint and running FieldConvert later.

I don't know how far I am from finishing this (some cases already work, but I still need to test it further). Anyway, it would be nice to have some feedback on it, especially regarding the compilation and general structure of the code, since I had to create a new FieldConvert library and move some files around.

See merge request !589

the Linf norm of p will be either 99.6778 or 99.6754 because depending
on the boost version, the rtree will give different results for cases where
points have the exact same distance.

Turns out gathering the coefficients is about ten times faster in parallel runs than doing the full fwd/bwd trans