There's no need for shared ownership here, as the only owning class
instance of those Cpu instances is the System class itself. We can also
make the thread_to_cpu map use regular pointers instead of shared_ptrs,
given that the Cpu instances will always outlive the cases where they're
used with that map.

Like the barrier, this is owned entirely by the System and will always
outlive the encompassing state, so shared ownership semantics aren't
necessary here.

This will always outlive the Cpu instances, since it's destroyed after
we destroy the Cpu instances on shutdown, so there's no need for shared
ownership semantics here.

key_manager/partition_data_manager: Minor changes

yuzu/main: Simplify OnMenuLoadFile()

video_core: Added ASTC 5x4; 8x5 types

filesystem: Make CreateFactories() and InstallInterface() take a VfsFilesystem by reference

Introduce 3D Swizzle seamlessly 

svc: Implement svcGetProcessInfo

Stop all threads on svcBreak

This should help diagnose crashes easier and prevent many users thinking that a game is still running when in fact it's just an audio thread still running(this is typically not killed when svcBreak is hit since the game expects us to do this)

A fairly basic service function, which only appears to currently support
retrieving the process state. This also alters the ProcessStatus enum to
contain all of the values that a kernel process seems to be able of
reporting with regards to state.

filesystem: Make CreateFactories() and InstallInterface() take a VfsFilesystem instance by reference

Neither of these functions alter the ownership of the provided pointer,
so we can simply make the parameters a reference rather than a direct
shared pointer alias. This way we also disallow passing incorrect memory values like
nullptr.

We can utilize QStringList's join() function to perform all of the
appending in a single function call.

While we're at it, make the extension list a single translatable string
and add a disambiguation comment to explain to translators what %1
actually is.

We can just reserve the memory then perform successive insertions
instead of needing to use memcpy. This also avoids the need to zero out
the output vector's memory before performing the insertions.

We can also std::move the output std::vector into the destination so
that we don't need to make a completely new copy of the vector, getting
rid of an unnecessary allocation.

Additionally, we can use iterators to determine the beginning and end
ranges of the std::vector instances that comprise the output vector, as
the end of one range just becomes the beginning for the next successive
range, and since std::vector's iterator constructor copies data within
the range [begin, end), this is more straightforward and gets rid of the
need to have an offset variable that keeps getting incremented to
determine where to do the next std::memcpy.

Aside from emplacing elements into the map, the map itself is never
actually queried for contained data.

These are only ever read from, so we don't need to make a copy of all
the keys here.

Given it's only used in one spot and has a fairly generic name, we can
just specify it directly in the function call. This also the benefit of
automatically moving it.

Commented out code shouldn't be left in without a reason indicating why
in a comment.

Instead, we can make it part of the type and make named variables for
them, so they only require one definition (and if they ever change for
whatever reason, they only need to be changed in one spot).

Given the VirtualFile instance isn't stored into the class as a data
member, or written to, this can just be turned into a const reference,
as the constructor doesn't need to make a copy of it.

Orders the members in the exact order they would be initialized. This
also prevents compiler warnings about this sort of thing.

Gets unused includes out of the headers and moves them into the cpp file
if they're used there instead.

If the data is unconditionally being appended to the back of a
std::vector, we can just directly insert it there without the need to
insert all of the elements one-by-one with a std::back_inserter.

If a conditional (or it's body) travels more than one line, it should be
braced.

Given the filesystem should always be assumed to be volatile, we should
check and bail out if a seek operation isn't successful. This'll prevent
potentially writing/returning garbage data from the function in rare
cases.

This also allows removing a check to see if an offset is within the
bounds of a file before perfoming a seek operation. If a seek is
attempted beyond the end of a file, it will fail, so this essentially
combines two checks into one in one place.

Given the file is opened a few lines above and no operations are done,
other than check if the file is in a valid state, the read/write pointer
will always be at the beginning of the file.

crypto: Add support for full key derivation

kernel/process: Make CodeSet a regular non-inherited object

Implemented helper function to correctly calculate a texture's size

svc: Fix typos in sanitizing checks for MapMemory/UnmapMemory