Automatic Fourier Transform setup on tensor fetch

[dschwen]

Add a method getReciprocalTensor<T> (figure out how to handle T). That automatically generates a ForwardFFT compute. Similarly, generate an InverseFFT object when obtaining the real space version of an existing reciprocal space tensor.

[dschwen]

Ok, this needs some more design considerations because it clashes with the automatic tensor buffer setup. We might have to ditch backward compatibility here.

Ideally the user would specify the name of a real space buffer and the tensor compute decides whether it needs a real space or reciprocal space representation.

Problem: currently there is no formal distinction between real space and reciprocal space buffers. Their names do not have to correspond in any way and some objects are perfectly happy to operate on either (ParsedCompute).

We can solve that by making two versions of ParsedCompute and introducing separate internal lists for real space and reciprocal tensors, and corresponding tensors would share the same name.

The NEML tensor types have no corresponding reciprocal space version, so for those we'd just fall back to regular torch::Tensors with a complex dtype and equal number of dimensions.

For explicit declaration of reciprocal space tensors we'll need a new syntax (as they would share block names with their real space counterparts).

Output will be limited to real space tensors, and if anyone ever wants to output a reciprocal space tensor, we'll add tensor computes to extract real/imaginary/phase/norm etc. into a real space tensor.

Ok, for sure to will break backwards compatibility and three changes will be required in inputs:

1. Do not explicitly declare reciprocal space tensors
2. Remove the input parameter in the forward and inverse FFT computes (those will be the same as the buffer name)
3. Replace all custom inverse FFT buffer names with the commpn real/reciprocal space name

Comments @chaibhave ?