We don't need to potentially inline the teardown logic of all of the
handle instances.

maxwell_3d: Initialize rasterizer color mask registers as enabled.

am: Correct build failure

- Fixes rendering regression with Sonic Mania.

The interface for shared memory was changed, but another commit was
merged that relied on the (previously public) internals of SharedMemory.

This amends that discrepancy.

kernel/shared_memory: Make data members private, plus minor interface changes

ldr: Clean up error codes

kernel/process: Move <random> include to the cpp file

common/assert: Make the UNIMPLEMENTED macro properly assert

file_sys/card_image: Provide named members for the GamecardInfo struct

Fills out the struct according to information provided by SwitchBrew

Currently, there's no way to specify if an assertion should
conditionally occur due to unimplemented behavior. This is useful when
something is only partially implemented (e.g. due to ongoing RE work).
In particular, this would be useful within the graphics code.

The rationale behind this is it allows a dev to disable unimplemented
feature assertions (which can occur in an unrelated work area), while
still enabling regular assertions, which act as behavior guards for
conditions or states which must not occur. Previously, the only way a
dev could temporarily disable asserts, was to disable the regular
assertion macros, which has the downside of also disabling, well, the
regular assertions which hold more sanitizing value, as opposed to
unimplemented feature assertions.

Currently, this was only performing a logging call, which doesn't
actually invoke any assertion behavior. This is unlike
UNIMPLEMENTED_MSG, which *does* assert.

This makes the expected behavior uniform across both macros.

<random> isn't necesary directly within the header and can be placed in
the cpp file where its needed. Avoids propagating random generation
utilities via a header file.

am: Implement HLE software keyboard applet

lm: Implement SetDestination by doing nothing

kernel/resource_limit: Clean up interface

Cleans out the citra/3DS-specific implementation details that don't
apply to the Switch. Sets the stage for implementing ResourceLimit
instances properly.

While we're at it, remove the erroneous checks within CreateThread() and
SetThreadPriority(). While these are indeed checked in some capacity,
they are not checked via a ResourceLimit instance.

In the process of moving out Citra-specifics, this also replaces the
system ResourceLimit instance's values with ones from the Switch.

This service function was likely intended to be a way to redirect where
the output of a log went. e.g. Firing a log over a network, dumping over
a tunneling session, etc.

Given we always want to see the log and not change its output. It's one
of the lucky service functions where the easiest implementation is to
just do nothing at all and return success.

This cleans up most of the callbacks and such in the Applets::Applet interface, while also properly implementing all four data channels.

hid: Add support for multiplayer and multilayout controllers

kernel/shared_memory: Make Map() and Unmap() take the target process by reference rather than as a pointer

Both member functions assume the passed in target process will not be
null. Instead of making this assumption implicit, we can change the
functions to be references and enforce this at the type-system level.

Given this doesn't mutate instance state, we can provide a
const-qualified variant as well.

Keeps the interface consistent with the regular Create() function.

Makes the interface nicer to use in terms of 64-bit code, as it makes it
less likely for one to get truncation warnings (and also makes sense in
the context of the rest of the interface where 64-bit types are used for
sizes and offsets

Rather than allow unfettered access to the class internals, we hide all
members by default and create and API that other code can operate
against.

The separate enum isn't particularly necessary here, and the values can
just be directly put into the ResultCode instances, given the names are
also self-documenting here.

Handles button configuration for all controller layouts and debug pads. Configurable at construction.

This allows adjusting the finger, diameter, and angle of the emulated touchscreen. It also provides a warning to the user about what changing these parameters can do.

Supports setting the five mouse buttons to any valid controller button/keyboard key (Left, Right, Middle, Foward, Back)

This moves the actual button configuration to a separate dialog and only has the enabled and type controls in the tab.