even shapes required for `real_domain_fft`

[VolkerH]

While experimenting with real_domain_fft I noticed that this has different input shape requirements compared to complex_domain_fft. As a result, pad_modes in ['none', '2357'] will throw an error for some input shapes.

A notebook to reproduce this is here:
https://github.com/VolkerH/flowdec/blob/realdomainexperiments/python/examples/notebooks/experimenting%20with%20real_domain%20option.ipynb

I first noticed this here:
VolkerH/Lattice_Lightsheet_Deskew_Deconv#37

Suggested fix:

• apply desired pad mode
• if real_domain_fft: check if shape after padding is odd in any dimension and increase shape by one.

It is not obvious whether handling pad_mode == None like this is desirable behaviour. If users don't want padding maybe a warning should be issued that padding happens anyway.

Edit:
While
https://www.tensorflow.org/api_docs/python/tf/signal/rfft3d
doesn't explicitly mention the permitted shape, the fact that fft_length / 2 positive-frequency terms are returned seems to confirm that even dimensions are rquired.