Add device keyword to fftfreq and rfftfreq

[steff456]

This PR,

• Adds device as arguments to fftfreq
• Adds device as arguments to rfftfreq

This PR fixes #500

[oleksandr-pavlyk]

Should we mention that only inexact data types, i.e. "real floating" and "complex floating" are expected to be supported?

[kgryte]

@oleksandr-pavlyk Updated the PR to require that dtype must be a floating-point data type. This work for you?

[rgommers]

This change matches the discussion. device seems clear. Just a question about dtype before we actually merge this though: is that actually useful in any real-world circumstance? I assume it would return the same values as for real dtypes, just with the .imag part all zeros?

[oleksandr-pavlyk]

@rgommers I was thinking the same thing. The dtype is always going to be dictated by data type of d, since d is allowed to be 0d array. If d is a Python scalar, then data type is either default real-valued or complex-valued floating-point type.

[steff456]

As discussed in our previous meeting, we are not going to add dtype as an argument.

[kgryte]

Found a previous issue on the NumPy issue tracker (numpy/numpy#9126) raised by @jakirkham concerning supporting a dtype keyword for fftfreq and rfftfreq. The PR implementing the feature (numpy/numpy#16496) was closed due to apparent implementation concerns, but not on merits.

[rgommers]

LGTM, this addresses gh-500 by adding the needed device keyword.

The dtype discussion seems to be of theoretical interest, but - given that no library actually implement it - of very limited practical value. Let's punt on that; if anyone actually needs it, let them implement it at least in numpy first.