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.

al/auxeffectslot.cpp

@@ -592,14 +592,12 @@ try {
             slot->Buffer = buffer;
             bufferlock.unlock();
 
-            auto statelock = std::unique_lock{device->StateLock};
             state->mOutTarget = device->Dry.Buffer;
             {
                 FPUCtl mixer_mode{};
                 state->deviceUpdate(device, buffer);
             }
             slot->Effect.State = std::move(state);
-            statelock.unlock();
 
             slot->mPropsDirty = false;
             slot->updateProps(context);
@@ -627,7 +625,6 @@ try {
             slot->Buffer = buffer;
             bufferlock.unlock();
 
-            auto statelock = std::unique_lock{device->StateLock};
             FPUCtl mixer_mode{};
             auto *state = slot->Effect.State.get();
             state->deviceUpdate(device, buffer);
@@ -899,7 +896,6 @@ ALenum ALeffectslot::initEffect(ALuint effectId, ALenum effectType, const Effect
         al::intrusive_ptr<EffectState> state{factory->create()};
 
         ALCdevice *device{context->mALDevice.get()};
-        std::unique_lock<std::mutex> statelock{device->StateLock};
         state->mOutTarget = device->Dry.Buffer;
         {
             FPUCtl mixer_mode{};