Add Polyend Tracker instrument (PTI) format support (read + write)

[douglas-carmichael]

Summary

Adds support for the Polyend Tracker instrument format (.pti) — used by the Polyend Tracker, Tracker Mini and Tracker+ — for both reading and writing. A PTI file is a single binary file holding one 16-bit / 44.1 kHz sample (mono or stereo) together with the instrument parameters. It is registered like every other format in ConverterBackend (CLI token polyendtracker).

Stacked on #149. This branch is based on the Renoise branch (#149), so until that PR is merged the diff here also contains its commits; afterwards it reduces to the single Polyend commit. The Polyend code itself is independent of the Renoise code.

What is converted

Read (.pti → multi-sample):

• Play mode, playback start/end and loop points, loop mode (forward / backward / ping-pong)
• Filter: low-, high- and band-pass with cutoff, resonance and the cutoff envelope
• Amplitude and pitch envelopes; volume, panning and coarse/fine tuning
• Slice / beat-slice instruments are split into one sample zone per slice, each trimmed to its own audio and mapped chromatically from MIDI note 60

Write (multi-sample → .pti):

• Play mode (one-shot or a loop mode), start/end and loop points, filter, amplitude/cutoff/pitch envelopes, volume, panning, tuning
• Audio converted to 16-bit / 44.1 kHz, mono or stereo preserved
• As the format holds only one sample, the zone covering MIDI note 60 (otherwise the first zone) is stored and the rest are ignored (a note is logged)

Implementation notes

• The binary layout was checked against the official Polyend tracker-lib reference and the factory SD-card content: a 16-byte header + 372-byte parameter block (audio at offset 388) + a trailing 4-byte checksum (written as zero, as factory files do).
• Playback start/end, loop and slice positions are stored proportionally to the sample length (0–65535), so they are scale-invariant and survive resampling.
• New code lives in format/polyend/ (PolyendTrackerDetector, PolyendTrackerCreator, PolyendTrackerConstants, PolyendTrackerValueConverter). No new settings classes — the detector uses the standard metadata settings and the creator has no options.

Testing

• All 70 factory .pti files (forward-loop, beat-slice, wavetable and granular play modes) detect without error.
• As a source: .pti → 23 of the 24 writable formats succeed. (The Maschine creator rejects its default "version 1" regardless of the source, which is unrelated to this change.) The SFZ output was verified by hand — slice key ranges, sample offsets, loop points, filter and volume are all correct.
• As a destination: the 20 formats that round-trip cleanly convert to .pti, and all 100 written files re-detect OK. The stereo de-interleave was verified to be a byte-perfect inverse, and a PTI → PTI round-trip is near-lossless (audio identical; loop points within ~0.01 % due to the proportional storage).

Caveat

⚠️ This has not been tested on physical Polyend Tracker hardware. It was validated only against the tracker-lib reference implementation and round-trip conversions within ConvertWithMoss.