This introduces a slightly more generic variant of WriteBuffer().
Notably, this variant doesn't constrain the arguments to only accepting
std::vector instances. It accepts whatever adheres to the
ContiguousContainer concept in the C++ standard library.

This essentially means, std::array, std::string, and std::vector can be
used directly with this interface. The interface no longer forces you to
solely use containers that dynamically allocate.

To ensure our overloads play nice with one another, we only enable the
container-based WriteBuffer if the argument is not a pointer, otherwise
we fall back to the pointer-based one.

Avoids pointless copies

- This can be used for domain objects as inputs to service functions.

* GetSharedFontInOrderOfPriority

* Update pl_u.cpp

* Ability to use ReadBuffer and WriteBuffer with different buffer indexes, fixed up GetSharedFontInOrderOfPriority

* switched to NGLOG

* Update pl_u.cpp

* Update pl_u.cpp

* language_code is actually language code and not index

* u32->u64

* final cleanups

* Stub PopLaunchParameter and implement Buffer C Descriptors reading

* Address PR feedback

* Ensure we push a u64 not a size_t

* Fix formatting

Popping objects from the buffer is still not implemented.

IPC: Use the correct size when pushing raw data to the command buffer and fixed pushing domain objects.

Domain object ids are always stored immediately after the raw data.

Reduces the necessary allocation to max(in_handles, out_handles) rather
than (in_handles + out_handles).

Copy the IPC command buffer to/from the request context before/after the
handler is invoked. This is part of a move away from using global data
for handling IPC requests.

The old "Interface" class had a few problems such as using free
functions (Which didn't allow you to write the service handler as if it
were a regular class.) which weren't very extensible. (Only received one
parameter with a pointer to the Interface object.)

The new ServiceFramework aims to solve these problems by working with
member functions and passing a generic context struct as parameter. This
struct can be extended in the future without having to update all
existing service implementations.

This allows attaching a HLE handle to a ServerPort at any point after it
is created, allowing port/session creation to be generic between HLE and
regular services.

Most of the code that works with this is or will be in the kernel, so
it's a more appropriate place for it to be.