Detect if length of array is too much for MKL to handle, warn if it is

[GarethCabournDavies]

In #4394 we moved to MKL as first preference, but #4395 shows that this is not always best - here we catch that issue and switch to fftw if it is appropriate add a warning

[josh-willis]

Please, please, please don't do this in this manner.

This is hard-coding in the lower levels of our infrastructure a current limitation of one FFT backend which could then change. And it's making a decision for the user who then has no way to override it.

We should raise the exception, and allow executables to choose to catch the exception if they can.

[GarethCabournDavies]

Would this be okay if I add in a test for whether the mkl backend was chosen as a default or as a specific choice through the cli? Then:

1. If the backend was set, don't change anything (but add a logging.warning)
2. If the default was used, then we will warn and switch

[josh-willis]

I just don't think this should be handled at the library level. Are you (personally) going to watch MKL release notes to know if this should change? Hard-coding this kind of thing is a mistake from a software-engineering point of view.

And I don't think there's a ready way to put this check where you want and to detect whether the backend was specifically requested or defaulted. There really shouldn't be a difference. If an end-user of the library is agnostic about the FFT backend, then they should put a try/except block in their executable.

[GarethCabournDavies]

Okay, I will add in a warning, but nothing more