Pica progress: Texturing, shaders, cleanups & more

This branch makes a number of big leaps towards more complete GPU emulation:
* Multitexturing: Supports up to 3 textures now
* Texture formats: Supports almost all uncompressed texture formats now
* Texture wrapping: Supports some texture wrapping modes now
* Tev emulation: Supports more features of the texture environment
* Shader input negation: The SRC2 input is now negated where required
* Shader instructions: The shader instructions MOVA, CMP, IFC, IFU and MAX are now supported. Additionally, bad emulation of the NOP and END instructions was corrected. The fact that not all instructions use the full 6 opcode bits is now considered.
* PrimitiveAssembly: Triangle strips are now supported.

Also fixes a number of bugs:
* The CommandProcessor code was written under the assumption that index arrays and vertex attribute arrays are stored in the same memory region (FCRAM<->VRAM). This obviously need not be the case.
* Ocarina of Time 3D tells us to use 8 input attributes, but only gives 2. Something's odd here, not sure what yet. Added a safety check to skip `nullptr`s, for now.

Additionally:
* we can now add breakpoints in the GPU debugger for individual input vertices (this will become very powerful once the shader debugger is complete).
* this branch imports the submodule nihstro as a hard dependency. nihstro's headers are used for decoding shader instructions and dumping shaders as SHBIN. nihstro's .cpp files are untouched for now.


NOTE: Windows build is probably broken still, but I'll fix it up eventually. Other than that, this branch is mostly good enough for code review though.

NOTE2: To get Ocarina of Time 3D to render something, you'll also need 5e97248e13caae56d035178a285794a47ed87314 and 6675b55455ebbf5061e467f8fcd46a8aea09dd25
Excuse me? `vertex_attribute_formats` is a constant-size array located on the stack... Do you mean  `vertex_attribute_sources` ? If so, how can that crash the emu? If anything I can see GetPointer failing to handle null addresses properly, and if it indeed does I'd say it's outside the scope of this PR to fix GetPointer (or to add workarounds for the broken GetPointer implementation).