Data methods: make consistent references to axes of arrays and axes of Data objects

[ddkohler]

This is an umbrella issue for the general idea that we almost always intend to use Data.axes to specify manipulations of the data, but array axes sometimes get used. This aspect hurts the transparency of the WrightTools API.

In some methods we use the idea that supplying an axis as an integer value implies you want the array axis, while supplying a string implies a Data axis. This is done especially in operations where operations are channel manipulations (e.g. in Data.gradient, Data.moment). However, this rule is not always enforced, which can make these operations confusing.

Some methods (e.g. Data.level, Data.smooth) strictly use array axes.

Proposal 1:

• Migrate channel manipulations (e.g. gradient, moment) as Channel/Dataset methods that accept array axis arguments
• Data objects will have wrappers/alternative methods that accept Data.axes/Data.variable arguments.

Proposal 2:

• always take axis arg to mean data axes, and have an additional optional kwarg array_axis to switch to use array axes.

Identified methods to address

• Data.level
• Data.smooth
• Data.gradient
• Data.moment

[ksunden]

I would only move things to be channel manipulations if they are independent of the values provided by the data axes.

This is certainly not true for moment (which is the only one I spot checked)

I think in most cases my initial reaction is that integer means "index of the underlying array", and string means "the axis with this name". I could be misremembering (it has been a while), but yeah. Sometimes those can even be mixed in the same argument. I do not recall using integer to mean "axis with this index in the ordered list of axes", though perfectly willing to be shown a case where that is what it means.