Refactor analysis functions to not rely on API provided by `Spectrum1D`

At this weeks SunPy community meeting we were discussing spectral analysis of solar data. One of the things we were discussing is how there is lots of functionality in `specutils` that could be of use to solar physicists, but for various reasons they might not want to use the `Spectrum1D` class.

Looking down the doc page for [Spectral Cubes](https://specutils.readthedocs.io/en/stable/spectral_cube.html) got me all excited because of the functional approach to analysis, the inheritance of `NDCube`, and relaxation of the position of the spectral axis, made me think I could apply some functions (like moment) to a generic `NDCube` or my `dkist.Dataset` subclass.
However, this lead me to the fact that it uses [`.flux`](https://github.com/astropy/specutils/blob/main/specutils/analysis/moment.py#L57-L58) which in turn [calls `u.Quantity`](https://github.com/astropy/specutils/blob/main/specutils/spectra/spectrum_mixin.py#L83) on the data which would cause all the Dask array backing a `dkist.Dataset` to be loaded into RAM.

More generically though, for the analysis functions provided by specutils to be generally applicable to data from different sources (instruments / missions) and different packages (dkist / ndcube / sunraster / specutils) I strongly feel that all the analysis code should be written for and tested against the base NDCube API.

Start by reading specutils/analysis/moment.py and specutils/spectra/spectrum_mixin.py, especially the referenced flux and Quantity usage. Review the Spectral Cubes documentation and the base NDCube API, then identify the analysis functions that depend on Spectrum1D. Done means the analysis code is written for and tested against NDCube without forcing Dask-backed data into memory.

Written by the indexing model from the issue text.