Support multiple voice-over channels

[ivan-mogilko]

This change is complementary to the previously added Game.PlayVoiceClip, which implemented non-blocking speech.
It turns out that some users require multiple voices played at the same time, for background speech.

1. Added explicit "Speech" audio type node. This node is "fixed" and cannot be deleted. Has MaxChannels = 1 by default, which reserves 1 channel for the speech. This should be backwards compatible, because AGS always had a hardcoded audio type at index 0, reserved for the speech (although it could not be accessed).
2. Game.SetAudioTypeVolume() now works for speech too.
3. Game.PlayVoiceClip() now plays the voice clip, searching for any free channel, according to the default rules.
4. Added optional "priority" and "repeat" parameters to PlayVoiceClip.

[ivan-mogilko]

This is working mostly, but there's another problem which I like to resolve.
I did not notice this back when adding PlayVoiceClip (afaik it was in 3.5.0 or 3.5.1), but when it's run with "as_speech" parameter, it shares a global flag with Say command, which leads to an accidental conflict: if a Say command without its own voice tag is run while background voice is playing, this flag affects its skipping behavior:

• skip by time is not happening while the bg voice is still playing;
• if you skip Say with a input, the bg voice will be also stopped.

This happens even if PlayVoiceClip and Say are referring for separate characters.

This is clearly a mistake, and I'd like to fix this. I'm just trying to figure out good rules for the behavior, assuming there may be multiple background voice-overs played at the same time, and also one blocking speech voice-over and bg voices at the same time.

[ivan-mogilko]

I had second thoughts, and will cancel this addition. While this is technically working, but there is still a number of concerns here. For instance, background speech may be worth making a separate audio type, and allow to have a volume drop when the "main" speech is playing too. But this means further change in design. Meanwhile, having multiple simultaneous voices is not a recurring request, and a rare use case.

Maybe this sort of support may be revisited later.

What I can do instead, is only apply internal changes that would make such redesign simpler in the future, while keeping existing behavior for now.