Add new CO track_frames and replace/deprecate track_samples

[acolombier]

Currently, a few features such as cue, loops but also waveform rendering relies on the track sample count to function properly. They all assume tracks being in stereo. This is misleading as the samples count isn't providing a useful information as there is no way to know if the count has been normalised to stereo (e.g for mono or stem tracks)

In order to clean this up, we should:

• Add a new CO track_frames which provide the true frame count of the loaded track (sample count/number of channel)
• Replace internal features relying on track_samples to use the frame count instead. Persistence (e.g for cues and loop) will continue using framecount x 2 to maintain backward compatibility)
• Deprecate track_samples in the code and in the manual in case user have built up integration with it. In the meantime, its value should be kept to framecount x 2 in order to ensure backward compatibility (e.g with custom community mapping)

Note that currently, there is no track_channels to provide the channel count (and allow computing the true sample counts) but it looks like that isn't something that can be of use just yet, so we should refrain from proactively adding this CO. if it gets required in the future, it should be trivial to add.

[JoergAtGithub]

This are not all COs, that use frames.

[acolombier]

That's right but it doesn't matter because track_samples's value is always framecount x 2, so even if some features do use sample counts (like loops and cues), they actually doesn't use the true sample count but always that framecount x 2, meaning they can be replaced with that new CO, and so we can expose "true" information, as opposite to falsify the sample count. Or did you mean something else?