Unmapping an unmapped buffer should succeed

nso/nro: Add support for passing command-line arguments to executable

Hardware tests show that trying to unmap an unmapped buffer already should always succeed. Hardware test was tested up to 32 iterations of attempting to unmap

Uses -p (--program) and following string as args.

Only added if arguments string is non-empty and a pass is requested by loader.

loader: Add support for packed updates

gl_rasterizer: Implement accelerated Fermi2D copies.

Implemented Depth Compare, Shadow Samplers and Texture Processing Modes for TEXS and TLDS

Port citra-emu/citra#4311: "Remove "#" in the version number"

Port citra-emu/citra#4140: "misc input tab improvements"

Port citra-emu/citra#4312: "Update fmt to 5.2.1"

Ported #4296 from citra

gl_rasterizer: Fixup undefined behaviour in SetupDraw

Port citra-emu/citra#4313: "CONTRIBUTING.md - remove note about casting numeric types"

So that people can stop using it in issue/pr comments and randomly link some other issue/pr unintentionally.

Apparently it's not true: https://github.com/citra-emu/citra/pull/4310#discussion_r223174725

* Added a context menu on the buttons including Clear & Restore Default

* Allow clearing (unsetting) inputs. Added a Clear All button

* Allow restoring a single input to default (instead of all)

It seems to fix msvc warnings

qt: Update telemetry links

These were pointing to a non-existent webpage.

This will allow us to easily remove the use of "NFC" in "System"

Port web_service from Citra

kernel/mutex: Amend behavior of TransferMutexOwnership()

This was the result of a typo accidentally introduced in
e51d7157. This restores the previous
correct behavior.

The behavior with the reference was incorrect and would cause some games
to fail to boot.

ui_settings: Place definition of the theme array within the cpp file

gl_rasterizer: Implement quads topology

thread: Make the scheduler pointer a regular pointer

Conceptually, it doesn't make sense for a thread to be able to persist
the lifetime of a scheduler. A scheduler should be taking care of the
threads; the threads should not be taking care of the scheduler.

If the threads outlive the scheduler (or we simply don't actually
terminate/shutdown the threads), then it should be considered a bug
that we need to fix.

Attributing this to balika011, as they opened #1317 to attempt to fix
this in a similar way, but my refactoring of the kernel code caused
quite a few conflicts.

kernel/thread: Make all instance variables private

text_formatter: Avoid unnecessary string temporary creation in PrintMessage()