Don't lock the device state when preparing a new effect state

Don't lock the device state when preparing a new effect state

There is technically a small race condition with the device getting reset on a
separate thread at the same time, but the way the locks get ordered would
otherwise risk a deadlock (alAuxiliaryEffectSloti first locks the context's
mPropLock and mEffectSlotLock before initEffect locks the device's StateLock,
while alcCreateContext and alcResetDeviceSOFT first locks the device's
StateLock before UpdateDeviceParams locks the context's mPropLock and
mEffectSlotLock).

In contrast, the race condition may (depending on timing) set up the effect
state with an older or mixed device format and assign invalid or null pointers,
which will get properly reset and cleaned up after the device is reconfigured
and before restarting.