[0.4.12][UMPNPMGR][USETUP] Fix the way device-install events are queued and dequeued...

[0.4.12][UMPNPMGR][USETUP] Fix the way device-install events are queued and dequeued. Fixes CORE-16103.

CORE-16103 "Network adapters sporadically fail to install with Code31 CM_PROB_FAILED_ADD"

This first and foremost reverts the guilty rev 0.4.12-dev-72-g 043a98ddd9969ceebf50682e296565dc11f25fc0
by porting back the fix 0.4.15-dev-1074-g ffc96d26ec297a6f9feec7c1e526efefa08809e0
the fix had to be adopted a bit for releases/0.4.12 due to some unrelated refactoring in umpnpmgr that has been
done during 0.4.13dev'ing.

------------
Dedicated to the hard work of Joachim Henze! xD

This reverts part of commit 043a98dd (see also commit b2aeafca).

Contrary to what I assumed in commit 043a98dd (and was also assumed in
the older commit b2aeafca), we cannot use the singled-linked lists to
queue and dequeue the PnP device-install events, because:

- the events must be treated from the oldest to the newest ones, for
  consistency, otherwise this creates problems, as shown by e.g. CORE-16103;

- the system singled-linked lists only offer access to the top of the
  list (like a stack) instead of to both the top and the bottom of the
  list, as would be required for a queue. Using the SLISTs would mean
  that only the newest-received events would be treated first, while the
  oldest (which were the first received) events would be treated last,
  and this is wrong.

Therefore one must use e.g. the standard doubly-linked list. Also, using
locked operations (insertion & removal) on the list of device-install
events is necessary, because these operations are done concurrently by
two different threads: PnpEventThread() and DeviceInstallThread().
Since the interlocked linked list functions are not available in user-mode,
we need to use instead locking access through e.g. a mutex.