Allow spectral-cube as an input type

[keflavich]

I tried running reproject_to_hips with a SpectralCube input and that failed.

The next obvious thing, reproject_to_hips(cube.hdu) (which is a bit potentially-dangerous because of loading TB into memory...) also failed with

ValueError: The input (VRAD) and output (FREQ-LOG) spectral coordinate types are not equivalent.

reproject_to_hips(cube.with_spectral_unit(u.GHz).hdu, ...) worked.

It would be better if we supported direct operation on spectral_cubes (and nddata cubes), but we should at least document the above limitations (apparently velocity frame isn't allowed output? or I need to specify it but I didn't immediately see how)

[astrofrog]

In principle I would be on board with this, but I wonder if to avoid growing the list of acceptable inputs for reproject we should instead define a magic method such as __reproject_input__ which data classes can define that would return an (array, wcs) tuple which can be used by reproject? In the case of SpectralCube, array could be a dask array.

@Cadair @svank @keflavich - what do you think?

[keflavich]

Sounds good to me.

[astrofrog]

Just to note that the spectral reprojection thing with the mismatching axes types is an issue which I will fix separately.

[Cadair]

I feel like Astropy already has NDData for this? And Reproject already accepts NDData.

The base NDData class is hardly overbearing, and it's an ABC right so you could register to it without subclassing?