Use flexible array members to pad the device and context structs

This helps avoid the convoluted math otherwise required to ensure the default
slot and listener, respectively, are aligned.
Add a generic vector interface and use it for the active effect slots
Use vectors for the GenModList
Rename the vector's Max field to Capacity
Increase the vector reserve as needed when pushing in new items
Avoid a size_t-to-ALuint conversion warning
Use a void* for the effect state Delete method param
Use a void* for the backend Delete method param
Use a void* for the MidiSynth Delete method param
Move some HRTF and mixer structs to alu.h
Add a stub 'soft' MIDI synth handler

Eventually this one will be used to handle MIDI internally, using our own
mixers and resamplers.
Don't try to use __restrict as a replacement for restrict

The compiler it's intended for, MSVC, can't use it anyway because of problems
it causes with __declspec(restrict).
Store the HrtfState directly in the DirectParams
Move the step counter and moving flag to DirectParams
Step mixing gains per-sample for non-HRTF mixing

This fades the dry mixing gains using a logarithmic curve, which should produce
a smoother transition than a linear one. It functions similarly to a linear
fade except that

step = (target - current) / numsteps;
...
gain += step;

becomes

step = powf(target / current, 1.0f / numsteps);
...
gain *= step;

where 'target' and 'current' are clamped to a lower bound that is greater than
0 (which makes no sense on a logarithmic scale).

Consequently, the non-HRTF direct mixers do not do not feed into the click
removal and pending click buffers, as this per-sample fading would do an
adequate job of stopping clicks and pops caused by extreme gain changes. These
buffers should be removed shortly.
Don't feed the HRTF mix to the click removal and pending click buffers

The coefficients (which control the volume and panning) already use stepping to
non-abruptly fade the mix.
Remove the now-unneeded click removal buffers for the device

They are still there for auxiliary sends. However, they should go away soon
enough too, and then we won't have to mess around with calculating extra
"predictive" samples in the mixer.