Added support for memory unit devices

[ergo720]

This adds support for a new input device, the memory unit (MU), which becomes available in the input gui when selecting the duke or S controller. For this cxbxr will now create a new folder called EmuMu in the same location where EmuDisk is created, and inside EmuMu there will be 8 folders, one for each MU. Regarding the internal code changes, this implements XMountMUA, XMountMURootA, XUnmountMU, XReadMUMetaData and extends the kernel functions NtQueryVolumeInformationFile, NtDeviceIoControlFile and NtFsControlFile to support MUs, in addition to the HDD. Below is a pic of the dashboard recognizing the MUs:

Testing is welcome.

[LanHikariDS]

Can confirm that TimeSplitters 2 and TimeSplitters: Future Perfect read from/write to them flawlessly-

[RadWolfie]

I had not made a full review, there's some changes need some fixes before I can re-review again.

I notice there are bunch of dev1 and port1 and the like which is not suitable to be use and lead confusion. Intead of using dev# and port#, they are actually iterator (in most cases), so using iDev and iPort, or i_dev and i_port, are preferred to be used.

[RadWolfie]

Beside code review, I tested the pull request's build with dashboard first, then Monopoly Party title.

I can confirm personalize MU names does work. And able to display the MU name in Monopoly Party title as seen below:

MU1A with personalize

MU1B without personalize (initialized by game title)

[RadWolfie]

Few code style changes and base on numerous to input mechanical not relative to memory unit devices. I recommended to perform full test with various titles that had been known to break in the past.

[RadWolfie]

Normally, DeviceMU should be move down to above DeviceMU0. But I can understand the group purpose.

[RadWolfie]

I'm not sure if we need this additional guard?

// Guard against the unfortunate case where XGetDevices or XGetDeviceChanges have already checked for g_bIsDevicesInitializing
// and g_bIsDevicesEmulating and a thread switch happens to this function

Quote from while (g_bXppGuard) {} line.

Can't we simply check both booleans than rely on additional variable, g_bXppGuard?

[ergo720]

UpdateXppState is only called from ConstructHleInputDevice and DestructHleInputDevice, both of which set g_bIsDevicesEmulating to true. The unfortunate case happens when XGetDevices or XGetDeviceChanges are called, find g_bIsDevicesEmulating = false, proceed, but then a thread switch happens to UpdateXppState. Without the guard, the latter will concurrently access the xpp type, which might cause issues depending on which xpp type XGetDevices and XGetDeviceChanges are using.

[RadWolfie]

Known titles experienced regression in the past has pass test by our tester.