We can simply enable CMAKE_AUTOUIC and let CMake take care of handling
the UI code generation for targets.

As part of letting CMake automatically handle the header file parsing,
we must not name includes with "ui_*" unless they're related to the
output of the Qt UIC compiler. Because of this, we need to rename
ui_settings, given it would conflict with this restriction.

Following screens got fixes:
- Configure/Debug
- Configure/Input

Prevents an invalid formatting exception from being thrown.

Gets rid of a compilation warning.

This commit ensures that the host gpu is constantly fed with commands to
work with, while the guest gpu keeps producing the rest of the commands.
This reduces syncing time between host and guest gpu.

This commit takes care of implementing the F16 Variants of the 
conversion instructions and makes sure conversions are done.

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.

Provides operational symmetry for the respective structures.

The return value is a u32, not an s32, so this would result in an
implicit signedness conversion.

This is the default behavior of the copy constructor, so it doesn't need
to be specified.

While we're at it we can make the other non-default constructor
explicit.

Results in less work being done where avoidable.

Same thing, but potentially allows a standard library implementation to
pick a more efficient codepath.

It's what it's there for.

Ensures that the constructor members are always initialized in the order
that they're declared in.

Prevents a truncation warning from occurring with MSVC. Also the
internal data structures already treat it as a size_t, so this is just a
discrepancy in the interface.

Previously, quite a few functions were being linked with external
linkage.

Makes it explicit that the conversions here are intentional.

This adds some missing puller methods. We don't assert them as these are 
nop operations for us.

This log was just to know which games used DMA. It's no longer 
important.

Textures can have different components types in different orders. This 
assert was completely inprecise and the effectiveness of such is better 
handled by case and within the texture cache.

This commit reduces the sevirity of asserts for FP precision and 
rounding as this are well known and have little to no consequences in 
gpu's accuracy.