Reads multiple dirs through as if a waterfall.

Maps a vector into the VFS interface.

Always returns the template argument byte for all reads. Doesn't support writes.

Maps name string to directory or file.

gl_stream_buffer: Fix use of bitwise OR instead of logical OR in Map()

This was very likely intended to be a logical OR based off the
conditioning and testing of inversion in one case.

Even if this was intentional, this is the kind of non-obvious thing one
should be clarifying with a comment.

* Added support for uncompressed NSOs

* Moved compressed section check to NsoHeader

travis: running mingw build on travis ci

yuzu-cmd: Add filesystem service initializer call

kernel/thread: Use owner_process when setting the page table in SetupMainThread()

arm_interface: Replace kernel vm_manager include with a forward declaration

RasterizerGL: Use the correct framebuffer when clearing via the CLEAR_BUFFERS register.

Previously we were clearing the default backbuffer framebuffer.

Found thanks to a Piglit test :)

file-sys: Default heavy-weight class destructors in the cpp file

game_list: Handle plurals within setFilterResult() better

Added IRequest::Submit

ring_buffer: Use std::hardware_destructive_interference_size to determine alignment size for avoiding false sharing

Revert GetRequestState

Even though setting this value to 3 is more correct. We break more games than we fix due to missing implementations. We should keep this as 0 for the time being

The owning process of a thread is required to exist before the thread,
so we can enforce this API-wise by using a reference. We can also avoid
the reliance on the system instance by using that parameter to access
the page table that needs to be set.

Avoids an unnecessary inclusion and also uncovers three places where
indirect inclusions were relied upon, which allows us to also resolve
those.

Correct endianness of BRK

externals: Update dynarmic to 171d116

This fixes updated versions of SMO. Currently unable to test as I don't have an updated version

savedata_factory: Add TemporaryStorage SaveDataType

control_metadata: Move language name array definition to the cpp file

xts_archive/nax: Minor interface changes

Implemented NTC & IEnsureNetworkClockAvailabilityService

Qt provides an overload of tr() that operates on quantities in relation
to pluralization. This also allows the translation to adapt based on the
target language rules better.

For example, the previous code would result in an incorrect translation
for the French language (which doesn't use the pluralized version of
"result" in the case of a total of zero. While in English it's
correct to use the pluralized version of "result", that is, "results"

---

For example:

English: "0 results"

French: "0 résultat" (uses the singular form)

In French, the noun being counted is singular if the quantity is 0 or 1.
In English, on the other hand, if the noun being counted has a quantity
of 0 or N > 1, then the noun is pluralized.

---

For another example in a language that has different counting methods
than the above, consider English and Irish. Irish has a special form of
of a grammatical number called a dual. Which alters how a word is
written when N of something is 2. This won't appear in this case with a
direct number "2", but it would change if we ever used "Two" to refer to
two of something. For example:

English: "Zero results"

Irish: "Toradh ar bith"

English: "One result"

Irish: "Toradh amháin"

English: "Two results"

Irish: "Dhá thorthaí" <- Dual case

Which is an important distinction to make between singular and plural,
because in other situations, "two" on its own would be written as "dó"
in Irish. There's also a few other cases where the order the words are
placed *and* whether or not the plural or singular variant of the word
is used *and* whether or not the word is placed after or between a set
of numbers can vary. Counting in Irish also differs depending on whether or not
you're counting things (like above) or counting people, in which case an
entirely different set of numbers are used.

It's not important for this case, but it's provided as an example as to why one
should never assume the placement of values in text will be like that of
English or other languages. Some languages have very different ways to
represent counting, and breaking up the translated string like this
isn't advisable because it makes it extremely difficult to get right
depending on what language a translator is translating text into due to
the ambiguity of the strings being presented for translation.

In this case a translator would see three fragmented strings on
Transifex (and not necessarily grouped beside one another, but even
then, it would still be annoying to decipher):

- "of"
- "result"
- "results"

There is no way a translator is going to know what those sets of words
are actually used for unless they look at the code to see what is being
done with them (which they shouldn't have to do).