Also, clang-format previous changes in provider.hpp.

This change introduces the ability to enable or disable the spoken interface/TTS from the on-device settings, either via the UI or the Lua console. This closes out the implementation of issue #245.

The TTS setting is only visible in Display settings if voice samples are present in `/.tangara-tts/` on the SD card.

Playback of new TTS voice samples is inhibited when TTS is disabled. By default, the setting is enabled, as the device will only play back TTS voices if samples are present on disk.

If you need samples to test TTS on your device, feel free to grab the voice samples I have at https://codeberg.org/tursiae/tangara-tts-samples. There's about 80-85% coverage of the UI, with the remainder to be added soonish.

Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/251
Co-authored-by: Tursiae <git@tursiae.org>
Co-committed-by: Tursiae <git@tursiae.org>

Reported in issue #258.

As of v1.2.0, if /.tangara-tts/ samples are present on the SD card, and
>= 4 menu items with matching TTS samples are highlighted in the UI, and
no audio output (headphones or BT sink) is connected, the `tts::Player`'s
invocation of lambdas on the WorkerPool will result in worker task
exhaustion.

This is because we get stuck in state where the `drivers::PcmBuffer` is
not accepting any new samples, and the inner loop in `Player::decodeToSink`
that pushes to the output isn't checking to see whether playback was
cancelled. So the loop never terminates, and we consume that worker slot.

Repeat with another 3 menu items, and, hey, all four worker threads are
consumed with TTS that will not terminate until headphones/BT are connected.

The extension is needed to trigger format detection in the tag reader.

 - input files are upsamples and padded to stereo before playback
 - any in-progress playback is cancelled before playing a new file