Introduce sigma_v + v_off, and remove line FWHM as a user-settable parameter

[jdtsmith]

A real ambiguity regarding the Model -> Features interface is what type of data is returned back into the Features table. The most principled approach is to return only details of the scientific model. The FWHM of a line is not such a detail.

Rather than letting users set that for unresolved lines, and having Model populate it after fit, it would be a cleaner approach if lines (and dust features) allowed an optional sigma_v (in km/s). sigma_v (default units: km/s) represents additional line width above and beyond that of the (Gaussian) instrumental line profile.

There are some details about applying sigma_v, but it's by far then the cleanest approach: all Features tables remain "unsullied" by artifacts of the instrumentation, and can hence be applied to any spectrum(/a) you throw at it (as long as they have valid instrument information)

Then fit, tabulate, plot, etc. would not need a way to "override the instrument". They are always applying instrument details of the plotted/tabulated/fitted spectrum(/a).

[jdtsmith]

Couple of issues: in some systems it might be necessary to allow a "forked" line with both a sigma_v and a v_off. I.e. you'd have a core line at the systemic velocity, and then a broadened component, at a slight shifted velocity. This should be highly constrained to work at all.

One issue this brings up: Fitter will need to know the instrument resolution for both these features, since it will be adding the underlying resolution in quadrature with the physical broadening term. It may be challenging to keep Fitter entirely out of the instrument game, because some instrument knowledge will be needed within the fit function itself.

[jdtsmith]

Thinking again, maybe Fitter only needs to know the (initial) central instrument resolution for lines, which it will already be getting, and sigma_v would just presume resolution is ~fixed over reasonable ranges of velocity spread and offset. For (narrow) Drude bands, we could also provide the internal Fitter set_feature_drude the same resolution (i.e. if it were a line).

Note that the Sara Profile remapping (#288) would happen generically at the Model level; if the science pack for some feature asks for, say 0.1–0.15µm, we'd know the "real" range to explore is 0.121-0.173µm (or whatever), and instruct our Fitter to use that range with the SaraProfile component.

It's much easier to reason if we assume features are ~fixed in instrument resolution even as they are varied.

[jdtsmith]

Re-reading the above, it seems clear a core + broad component should just be introduced as two independent (or tied) features.