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.

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

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.

Including finger ID, diamater x/y, and angle. Additionally, checks if the touchscreen is enabled.

Used by developers to test games, not present on retail systems. Some games are known to respond to DebugPad input though, for example Kirby Star Allies.

Defaults to full keyboard for keyboard -- It did not seem to be necessary to make the keyboard configurable (besides enabled/disabled).

Uses the PlayerInput struct to represent all of the data that constitutes a player.

textures/decoders: Replace magic numbers