ControllerInterface: fix UpdateReferences() deadlock

Removed useless locks to DeviceContainer::m_devices_mutex, as they were all already protected by m_devices_population_mutex.
We have no interest in blocking other threads that were potentially reading devices at the same time so this seems fine.
This simplifies the code, and I've adjusted a few comments which mentioned possible deadlock that should now be totally gone.

The deadlock could have happen if a thread directly called EmulatedController::UpdateReferences(), while another another thread also reached EmulatedController::UpdateReferences() within a call to ControllerInterface::UpdateDevices(), as the mentioned function locked both the DeviceContainer::m_devices_mutex and s_get_state_mutex at the same time.

The deadlock was frequent on game emulation startup on Android, due to the UpdateReferences() call in InputConfig::LoadConfig() and the UI thread triggering calls to ControllerInterface::UpdateDevices().
It could also have happened on Desktop if a user pressed "Refresh Devices" manually in the UI while the input config was loading.

Also brought some UpdateReferences() comments and thread safety fixes from https://github.com/dolphin-emu/dolphin/pull/9489

Source/Core/DolphinQt/Settings.cpp

@@ -80,8 +80,7 @@ Settings::Settings()
       // they'd continue living until the queued event has run, but some devices can't be recreated
       // until they are destroyed.
       // This is safe from any thread. Devices will be refreshed and re-acquired and in
-      // DevicesChanged(). Waiting on QueueOnObject() to have finished running was not feasible as
-      // it would cause deadlocks without heavy workarounds.
+      // DevicesChanged(). Calling it without queueing shouldn't cause any deadlocks but is slow.
       emit ReleaseDevices();
 
       QueueOnObject(this, [this] { emit DevicesChanged(); });