Fix pulseaudio locking

[sqweek]

@illuusio I think you're right about wrapping the context calls with locks. thread-mainloop.h says:

The added feature in the threaded main loop is that it spawns a new thread
that runs the real main loop. This allows a synchronous application to use
the asynchronous API without risking to stall the PulseAudio library.

And then goes on to discuss locking:

Since the PulseAudio API doesn't allow concurrent accesses to objects,
a locking scheme must be used to guarantee safe usage. The threaded main
loop API provides such a scheme through the functions
pa_threaded_mainloop_lock() and pa_threaded_mainloop_unlock().

The lock is recursive, so it's safe to use it multiple times from the same
thread. Just make sure you call pa_threaded_mainloop_unlock() the same
number of times you called pa_threaded_mainloop_lock().

The lock needs to be held whenever you call any PulseAudio function that
uses an object associated with this main loop. Make sure you do not hold
on to the lock more than necessary though, as the threaded main loop stops
while the lock is held.

It also explictly says that the lock must be held when calling pa_threaded_mainloop_wait. So this means all the stuff in PaPulseAudio_Initialize does need to happen while locked, therefore I've reinstated the locks that were removed in 207937b (actually I just hold the lock for the whole time we are doing pulse stuff). The only other place I could find making a pulse call without the lock held was Terminate.