Treatment of non-height data channels

The problem

Many file formats support non-height information, for example the piezo voltage and others. Right now some readers return those channels (DI, IBW) while some do not (EZD, GWY).

The goal

Moving forward with the code base, I think we want to support non-height data channels and should implement reading those. Issues to resolve are:

Possible solution

1) We need to report two units - lateral unit and data unit. Suggestion: If information is not-height, then unit should be a tuple with lateral unit first and data unit second. This would not break most of the downstream codes.

2) Some properties have explicitly height in the names, e.g. the method heights() or the height_scale_factor. We should change the API to reflect this (maybe deprecating heights in the long run).

3) The channel index is currently used to uniquely refer to the data channel. Those indices would change if we just remove skipping of non-data channels in DI and IBW readers. This will break downstream topobank badly, because the channel index is stored verbatim in the database to refer to a specific channel. There should be a unique channel-indexing scheme that is invariant to the actual order of channels in the data file. Note that the channel name cannot be used as there are data files that have multiple channels of the same name. We could of course normalize that name by appending an index, but then the order matters again.

4) Some of the code is currently specific to height, e.g. unit name mangling. We should probably move this to a third-party library such as pint.

ContactEngineering / SurfaceTopography