Don't allow multiple playaiff() threads.

Don't allow multiple playaiff() threads.

If there's already a playaiff() thread going when another playaiff()
thread is to be started, tell the first one to stop and clean up, then
join to it when it terminates before proceeding to start another
playaiff() thread.  This will cleanly handle a barrage of samples called
to start in quick succession.  For example, suppose your game has
several buttons that make noises.  Doing "PRESS GREEN BUTTON. PRESS BLUE
BUTTON. PRESS RED BUTTON. PRESS YELLOW BUTTON" will not cause playaiff()
to trip over itself.  Instead all the samples will be played briefly
except the one for the yellow button, which will play until the player
does something else noisy at the next command prompt.  What's actually
heard is the last button noise.  Such a reaction probably isn't
desirable, but is well-within the responsibility of the game author to
decide if and how AIFF samples will be allowed to stomp on one another.
The business about allowing only one AIFF at a time and one OGG/MOD at a
time, but mix the two comes from the fact that all other Z-machine
emulators with audio capability behave this way.  The Z-machine spec
clearly says that only one sample (AIFF) may be played at once.  I don't
know where the idea that allowing an OGG/MOD to be mixed came from or
who decided it was okay.  The Blorb specs seem silent on the issue of
having multiple AIFFs and OGG/MODs playing at once.