Remove the redundant s_populate_mutex and only use
ControllerInterface::m_devices_population_mutex instead to prevent a
deadlock caused by locking them in opposite orders.

The device population functions in the win32 InputBackend previously
locked s_populate_mutex first before calling various functions that
locked m_devices_population_mutex. This normally worked but
ControllerInterface::RefreshDevices locks m_devices_population_mutex
first and then calls HandleWindowChange which then locked
s_populate_mutex, potentially causing the deadlock.

Fix this by using PlatformPopulateDevices to lock
m_devices_population_mutex before running the code that was previously
protected by s_populate_mutex. The functions in question lock
m_devices_population_mutex anyway, so this shouldn't meaningfully
increase contention on the lock.

Reproduction steps:

* Let Dolphin finish startup.
* In Win32.cpp::OnDevicesChanged set a breakpoint on the call to
  PlatformPopulateDevices. When the breakpoint is triggered the function
  will have locked s_populate_mutex, but since PlatformPopulateDevices
  won't have run yet m_devices_population_mutex will still be unlocked.
* Unplug a device from your computer.
* Wait for the breakpoint to trigger. (At this point you can plug the
  device back in).
* Freeze the ntdll.dll!TppWorkerThread() that triggered the breakpoint.
* Resume Dolphin and start a game.
* Core::EmuThread will call ControllerInterface::ChangeWindow which
  calls RefreshDevices. It locks m_devices_population_mutex, then calls
  InputBackend::HandleWindowChange, which tries to lock
  s_populate_mutex.
* Unfreeze ntdll.dll!TppWorkerThread().

At this point EmuThread and TppWorkerThread are deadlocked. The UI is
still responsive since the Host thread is unaffected, but trying to stop
the game or close Dolphin normally will fail since EmuThread is unable
to stop.

other things (like SDL) may try to use "Message"

Note that D3DCommon can't use DX11HRWrap or DX12HRWrap since it's shared between them.

Fixes bug: https://bugs.dolphin-emu.org/issues/12744

Before https://github.com/dolphin-emu/dolphin/commit/e1e3db13baabefa89991388d37db0bb260c4f535
the ControllerInterface m_devices_mutex was "wrongfully" locked for the whole Initialize() call, which included the first device population refresh,
this has the unwanted (accidental) consequence of often preventing the different pads (GC Pad, Wii Contollers, ...) input configs from loading
until that mutex was released (the input config defaults loading was blocked in EmulatedController::LoadDefaults()), which meant that the devices
population would often have the time to finish adding its first device, which would then be selected as default device (by design, the first device
added to the CI is the default default device, usually the "Keyboard and Mouse" device).

After the commit mentioned above removed the unnecessary m_devices_mutex calls, the default default device would fail to load (be found)
causing the default input mappings, which are specifically written for the default default device on every platform, to not be bound to any
physical device input, breaking input on new dolphin installations (until a user tried to customize the default device manually).

Default devices are now always added synchronously to avoid the problem, and so they should in the future (I added comments and warnings to help with that)