Making the parser more closely resemble the N64 libs about mpkedit

[bryc]

Aug 11: headerCheck handles the required bits properly. I removed the strict-checking for 00 00 00 00 in the gameCode field, because it didn't make sense - some notes were perfectly parsable despite having an invalid gameCode, no sense in causing it to break a perfectly valid file.

In the future, the MPKParser should be adapted to be able to salvage valid data and delete invalid data, which is what the Controller Pak library does. (Pertaining to the INODE table)

Note/recap (Nov 23 2016): I wrote this after doing a bunch of testing and seeing just how verbose the official controller pak library is, hence why I want to study it further and follow the lib behaviour more closely.

[bryc]

Eventually I will get around to doing game tests to understand these constraints, as well as the unknown bytes. Issue 8 would also fall into those tests.

The whole idea of "making the parser follow the libs" means that my app must do more than just parse the data. I'm trying to keep unintended modification to a minimum. The n64 libs include a lot of recovery functions, like salvaging valid data from invalid data, which my parser does not do. This should be optional and a prompt to the user "This file is damaged. Continue loading only valid data? Some data may be lost."

[bryc]

Different games may have different versions of the ultra64 library, or may have implemented their own functions for dealing with MPK. Important to keep that in mind, that the code for these functions is contained in the game itself, and may differ between games.