This option allows picking the compatibility profile since a lot of bugs
are fixed in it. We devs will use this option to easierly debug current
problems in our Core implementation.:wq

The default constructor will always run, even when not specified, so
this is redundant.

However, the context member can indeed be initialized in the constructor
initializer list.

This include isn't used anymore so it can be removed.

Resolves -Wreorder warnings. These will automatically be initialized to
nullptr anyways, so these were redundant.

This is a compile definition introduced in Qt 4.8 for reducing the total
potential number of strings created when performing string
concatenation. This allows for less memory churn.

This can be read about here:
https://blog.qt.io/blog/2011/06/13/string-concatenation-with-qstringbuilder/

For a change that isn't source-compatible, we only had one occurrence
that actually need to have its type clarified, which is pretty good, as
far as transitioning goes.

Without passing in a parent, this can result in focus being stolen from
the dialog in certain cases.

Example:

On Windows, if the logging window is left open, the logging Window will
potentially get focus over the hotkey dialog itself, since it brings all
open windows for the application into view. By specifying a parent, we
only bring windows for the parent into view (of which there are none,
aside from the hotkey dialog).

Without a parent, this dialog won't have its memory freed when it
happens to get destroyed.

This is checking if an index is valid or not and returning early if it
isn't.

Avoids a -Wreorder compiler warning.

Avoids dumping all of the core settings machinery into whatever files
include this header. Nothing inside the header itself actually made use
of anything in settings.h anyways.

This doesn't actually modify instance state of the dialog, so this can
be made const.

In our error console, when loading a game, the strings:

QString::arg: Argument missing: "Loading...", 0
QString::arg: Argument missing: "Launching...", 0

would occasionally pop up when the loading screen was running. This was
due to the strings being assumed to have formatting indicators in them,
however only two out of the four strings actually have them.

This only applies the arguments to the strings that have formatting
specifiers provided, which avoids these warnings from occurring.

This doesn't actually work anymore, and given how long it's been left in
that state, it's unlikely anyone actually seriously used it.

Generally it's preferable to use RenderDoc or Nsight to view surfaces.

- Use QStringLiteral where applicable.

- Use const where applicable

- Remove unnecessary precondition check (we already assert the pixbuf
  being non null)

We can utilize qOverload with the signal connections to make the
function deducing a little less ugly.

Fills in the missing surface types that were marked as unknown. The
order corresponds with the TextureFormat enum within
video_core/texture.h.

We also don't need to all of these strings as translatable (only the
first string, as it's an English word).

While we're at it, don't use <QtGui> and <QtWidgets> and instead include
exactly which headers we actually need.

Allows these strings to have no allocation cost when used at runtime.

Rather than scream that the file doesn't exist, we can clearly state
what specifically doesn't exist, to avoid ambiguity, and make it easier
to understand for non-primary English speakers/readers.

We can just make the trailing portion of the string part of the
formatting, getting rid of the need to make another temporary string.

Simplifies the amount of string conversions necessary. We also don't
need to log out what occurs here.

There's no need to construct a QFile instance just to check for its
existence.

Like the previous change, this allows Qt to handle proper translations
of the UI buttons, rather than us needing to handle it.

Makes for shorter code, while also not requiring the buttons to be
directly translated, they'll be handled by Qt itself.

Moves includes into the cpp file where necessary. This way,
microprofile-related stuff isn't dumped into other UI-related code when
the dialog header gets included.

Since C++17, the introduction of deduction guides for locking facilities
means that we no longer need to hardcode the mutex type into the locks
themselves, making it easier to switch mutex types, should it ever be
necessary in the future.

This was initially added to prevent problems from stubbed/not implemented NFC services, but as we never encountered such and as it's only used in a deprecated function anyway, I guess we can just remove it to prevent more clutter of the settings.

While we are at it, remove nullptr checks for deletion, since the C++
standard defines that delete does it by its own

# Conflicts:
#	src/video_core/engines/kepler_memory.cpp
#	src/video_core/engines/maxwell_3d.cpp
#	src/video_core/morton.cpp
#	src/video_core/morton.h
#	src/video_core/renderer_opengl/gl_global_cache.cpp
#	src/video_core/renderer_opengl/gl_global_cache.h
#	src/video_core/renderer_opengl/gl_rasterizer_cache.cpp

* Adds a new Hotkeys tab in the Controls group.
* Double-click a Hotkey to rebind it.