Have box_smooth accept spectral axis units instead of just pixels

[eteq]

Right now, specutils.manipulation.box_smooth only accepts pixels as the width. It would be more convenient for some cases if it instead accepted spectral axis units, because that's a lot easier to compare across spectra - e.g. if I have data and a template and want them smoothed to the same resolution, I would rather give it in angstroms than have to figure out the number of pixels by hand.

While the API per se is simple, there's a complexity here in that most spectra do not have a fixed pixel-to-spectral conversions - most are relatively mildly (<~10%) non-linear, although there are exceptions.

Since this is at some level a convenience given that the smoothing actually happens in pixel space, my proposal would be to do something simple and straightforward like: 1 .compute the delta-wavelength between pixels (e.g. numpy.diff)

2. take the median of that to get a pixel/{spectral_axis_unit}.
3. use the astropy spectral equivalency to convert the requested box size to the spectral_axis unit
4. multiple by the result of 2 to get the pixel box size

That's good enough for most "close-to-linear" wavelength axes and is at least not totally meaningless for less-linear axes. We should be sure to note in the docs something like "if your spectral axis is highly non-linear, you may be better off not using this feature" though.

[eteq]

Note in #603 I suggest maybe the algorithm I've outlined above could also be a public utility function to allow it to be used with convolution_smooth. We'd still want it to be auto-used inside box_smooth, but be implemented as a public function to be available elsewhere as needed.

[hcferguson]

I can see some benefit of leaving the API alone (for now), rather than adopting this partial solution.

Since the documentation has to tell people how to deal with smoothing kernels with non-linear wavelength solutions anyway it seems cleaner to have a section on that issue in the documentation. That section could provide examples of (1) how to convert your kernel width from physical units to pixels, if you want to do that, (2) how to resample to linearize your pixel scale, and why you might want to do that first, or (3) how to (for now) do the linearization temporarily, convolve with the appropriate kernel, and return back to the original sampling (a workflow that might deserve its own function in specutils down the road).