This appears to be a vestigial API function that's only kept around for
compatibility's sake, given the function only returns a success error
code and exits.

Since that's the case, we can remove the stubbed notification from the
log, since doing nothing is technically the correct behavior in this
case.

kernel/svc: Log out uncaught C++ exceptions from svcBreak

video_core: Silent implicit conversion warning

Port citra-emu/citra#4601: "dsp_interface: fix sound being played while volume is 0"

Looking into the implementation of the C++ standard facilities that seem
to be within all modules, it appears that they use 7 as a break reason
to indicate an uncaught C++ exception.

This was primarily found via the third last function called within
Horizon's equivalent of libcxxabi's demangling_terminate_handler(),
which passes the value 0x80000007 to svcBreak.

According to documentation, if the argument of std::exp is zero, one is returned.
However we want the return value to be also zero in this case so no audio is played.

video_core: Replace gl_shader_decompiler with an IR based decompiler

frontend: Refactor ScopeAcquireWindowContext out of renderer_opengl.

Port citra-emu/citra#3928: "citra_qt: Log settings on launch"

ISSUE_TEMPLATE: changes to make it more expressive and prevent low-quality issues

maxwell_3d: Set rt_separate_frag_data to 1 by default

Commercial games assume that this value is 1 but they never set it. On
the other hand nouveau manually sets this register. On
ConfigureFramebuffers we were asserting for what we are actually
implementing (according to envytools).

yuzu/configuration: Remove unnecessary inclusions where applicable

Loading progress bar upgrades

QT Frontend: Add a Loading screen with progressbar

gl_rasterizer_cache: Use dirty flags for framebuffers

gl_rasterizer: Use DSA for VAOs and buffers

yuzu/configuration/configure_web: Amend verification string

loader: Add getters for application banner and logo

With shader caches on the horizon, one requirement is to provide visible
feedback for the progress. The shader cache reportedly takes several
minutes to load for large caches that were invalidated, and as such we
should provide a loading screen with progress.

Adds a loading screen widget that will be shown until the first frame of
the game is swapped. This was chosen in case shader caches are not being
used, several games still take more than a few seconds to launch and
could benefit from a loading screen.

yuzu/web_browser: Minor cleanup

gl_rasterizer: Silent unsafe mix warning

file_sys/directory: Remove unused DirectoryBackend class

This isn't used at all, so we can just get rid of it.