Adding fast multipole method for Legendre-Chebyshev transforms

[mikaem]

This PR adds code originally found in the https://github.com/spectralDNS/Legendre-to-Chebyshev repository. The code should work for single and double precision, but has not been tested for anything else. Basically, there is now

1. A planner in create_fmm or in order to apply the transform to a 2D matrix: create_fmm_2d
2. An executioner in execute

Usage:

size_t N = 1024;
FLT *input_array = (FLT *)calloc(N, sizeof(FLT)); // should be initialized
FLT *output_array = (FLT *)calloc(N, sizeof(FLT));
X(fmm_plan) *fmmplan = X(create_fmm)(N, maxs, M, BOTH, lagrange, verbose);
X(execute)(input_array, output_array, fmmplan, L2C, 1);
free(input_array);
free(output_array); 
X(free_fmm)(fmmplan);

where 'N' is the size of the 1D transform, 'fmm_plan' is a struct holding all necessary data for the transforms, 'maxs' is half the size of the smallest hierarchical submatrices, 'M' is the order of the Chebyshev approximation on the submatrices, 'BOTH' indicates that you should plan for both forward L2C and backward C2L transforms. Using either C2L or L2C and the plan will only be initialized for the given direction. The 'lagrange' argument is boolean and if 0 it is using a modal approach, whereas 1 leads to a nodal (the original of Alpert et al) approach. The 'verbose' is an integer and if 0 printing is minimised, whereas 2 leads to some printing, especially in the planning.

3. The function names should probably be altered to be in line with the rest of the repository.
4. The single precision seems to work, but it should be improved. It is actually the reason why FFTW is needed, because FFTW is used to do a DCT on the input matríces of shape 8x8. This can easily be hardcoded for efficiency, like it has been for double precision, where the matrices are of size 18x18.
5. If required, the FFTW dependency can be removed.

[mikaem]

I'm expecting the mac runners to fail since they do so on my fork, but they do not fail for my code so I think I need some help here @MikaelSlevinsky

[MikaelSlevinsky]

Thank you for the contribution! It seems the macOS issue is that the runner does not respect the exclusion of arm64 on macOS-latest, but it does so on macOS-13, which I just tested. So I think I'm happy to merge!