feature: Refactor music engine to prepare for advanced transitions

[piotrmacha]

MusicTheme & MusicManager

MusicDef is replaced by MusicTheme. MusicManager is a new class for holding all music themes. Music themes are loaded directly from scripts at the start instead of waiting for CMusicSys_Bass.

New themes support multiple audio files for advanced transitions.

Executors & Thread Pool

Added Executor abstraction, which lets us execute some task on some executor. Now, we have two:

• InstantExecutor: executes the task when it's added
• ThreadPool: runs a pool of N threads and adds tasks to the queue, which is read by threads that execute the task

A ThreadPool executor is used by MusicManager to load music files in the background.

Command Model

Engine::Play() function is replaced by a command queue to support future development of TransitionScheduler which can push multiple different events on the queue to execute individual operations at a specific time. It's also a nice design pattern to encapsulate the possible operations.

For example, the CMusicSys_Bass adds ChangeZoneCommand(zoneId) to the queue which checks if any theme supports this zone. If it does, then it adds ScheduleThemeChangeCommand(themeId) to the queue, which passes the theme to TransitionScheduler.

TransitionScheduler decides what to do and also adds commands to the queue. Currently, it's using only PlayThemeCommand(themeId, audioId), which plays the theme in a backwards-compatible way (does cross-fade transition). In the future, more commands can be added so TransitionScheduler can execute more complicated workflows.

Development QoL

HashString now has a default constructor and holds the source string. It also has an implicit cast operator to NH::String.

HasToString interface is added with a String ToString() method and implicit cast to NH::String. Classes can implement it to display their structure in logs (example: MusicTheme), which is more readable than std containers in a debugger.