Clean-up filenames generated for audio recordings

[Randesign]

I propose changes to the file names used in recorded audio files to make them more consistent for external software to extract the information fields from the file names.

Currently generated recording file names have the format:

date_time<no delimiter>system_site_channel_etc...
example: 20250108_192900CO_DTRS_Thorodin_T-Thorodin_CC__TO_9100.mp3

I propose the following changes to the record file names.
• Replace underscore between date and time with “T”. This makes it ISO 8601 compatible.
• Use underscore as a delimiter between fields (already mostly implemented).
• Add an underscore between the timestamp and the system name. Currently there is none.
• Instead of replacing illegal characters and spaces in file names with “_”, replace them with dash “-” to allow for underscore to be used as a field delimiter.

This would make the format:
dateTtime_system_site_channel_etc...
example: 20250108T192900_CO-DTRS_Thorodin_T-Thorodin-CC__TO_9100.mp3

If there is support for this, I am happy to fork/PR. Changes are minimal and appear to only affect two source files.

[kernworks]

See #833 also.
Not identical but close. It also seems to be on the development roadmap.

[DSheirer]

Yes, I support this. However, some 3rd party integrations (trunking recorder) currently ingest the files, so I'll need to make sure this change doesn't break their implementation.

[jasoveen]

Trunking Recorder does not use the filename data when reading recorded files from SDRTrunk (it uses the ID3 and WAV tags for all the metadata) so the proposed changes should not cause any issues.

[Randesign]

With a deeper look at the code, my proposed changes would also affect other files created by sdrtrunk, such as event logs and binary recordings.

I don't see much issue with the dashes (4th bullet point in original post).

However while changing the timestamp format (1st bullet point) can be done to only affect audio recordings, it leads to inconsistency across the app, with different timestamp formats for event logs and other recordings. I would like direction on which approach to take on this. I'm fine with leaving the date time separator as an underscore 20250108_192900 (instead of changing to a "T" for ISO 8601), or I can change all instances of the timestamp format with respect to paths for audio, events, etc. so that it's consistent across the app.