Purpose of Ioctl2 and Ioctl3 is to prevent the passing of raw pointers through ioctls

Avoids the use of global accessors, removing the reliance on global
state. This also makes dependencies explicit in the interface, as
opposed to being hidden

Corrects the parameter names within the doxygen comments so that they
resolve properly.

Narrows the scope of variables down to where they're only necessary.

* AM: Implement IApplicationFunctions::GetGpuErrorDetectedSystemEvent

* Remove unneeded event clear

* Fix event name

Co-Authored-By: David <25727384+ogniK5377@users.noreply.github.com>

We can remove this since its already a f32 value

Volume is a f32 value. (SwIPC describes it as a u32, but it is actually f32 as corroborated by switchbrew docs and SetAudioDeviceOutputVolume)

 ```cpp
const f32 volume = rp.Pop<f32>();
```

If an unmapping operation fails, we shouldn't be decrementing the amount
of memory mapped and returning that the operation was successful. We
should actually be returning the error code in this case.

Avoids potentially expensive (depending on the size of the memory block)
allocations by reserving the necessary memory before performing both
insertions. This avoids scenarios where the second insert may cause a
reallocation to occur.

Avoids an unnecessary atomic reference count increment and decrement.

Avoids needing to read the same long sequence of code in both code
paths. Also makes it slightly nicer to read and debug, as the locals
will be able to be shown in the debugger.

Same behavior, one less magic constant to read.

Assertions already log out the function name, so there's no need to
manually include the function name in the assertion strings.

This commit ensures that all backing memory allocated for the Guest CPU
is aligned to 256 bytes. This due to how gpu memory works and the heavy
constraints it has in the alignment of physical memory.

Audio devices use the supplied revision information in order to
determine if USB audio output is able to be supported. In this case, we
can only really handle using this revision information in
ListAudioDeviceName(), where it checks if USB audio output is supported
before supplying it as a device name.

A few other scenarios exist where the revision info is checked, such as:

- Early exiting from SetAudioDeviceOutputVolume if USB audio is
  attempted to be set when that device is unsupported.

- Early exiting and returning 0.0f in GetAudioDeviceOutputVolume when
  USB output volume is queried and it's an unsupported device.

- Falling back to AHUB headphones in GetActiveAudioDeviceName when the
  device type is USB output, but is unsupported based off the revision
  info.

In order for these changes to also be implemented, a few other changes
to the interface need to be made.

Given we now properly handle everything about ListAudioDeviceName(), we
no longer need to describe it as a stubbed function.

The revision querying facilities are used by more than just audren. e.g.
audio devices can use this to test whether or not USB audio output is
supported.

This will be used within the following change.

Trims out the lingering reliance on global state out of the audio code.

This service function only ever returns a result and nothing more.

AudioDevice and AudioInterface aren't valid device names on the Switch.
We should also be returning consistent names in
GetActiveAudioDeviceName().

While we're at it, we can also handle proper name output in
ListAudioDeviceName, by returning all the available devices on the
Switch.

This messages were originally set as warnning since few games used these
svcs and it was needed for debugging. This is no longer the case.

Creating multiple "AudioRenderer" threads cause the previous thread to be overwritten. The thread will name be renamed to AudioRenderer-InstanceX, where X is the current instance number.

This simply queries whether or not auto-sleep facilities are disabled
and has no special handling. It's a basic getter function.

Provides a basic implementation of SetAutoSleepDisabled. Until idle
handling is implemented, this is about the best we can do.

In the meantime, provide a rough documenting of specifics that occur
when this function is called on actual hardware.