Making the parser more closely resemble the N64 libs

[bryc]

parseNoteTable:

1. gameCode typically must exist, and cannot be 00 00 00 00. Most games rely on this for identifying associated notes. For example, Gex 64 (NX2E) relies on the noteName only (In the format GEX:%s), and any gameCode will function as long as it's not completely empty.
2. publisherCode also typically must exist, and cannot be 00 00 although some games don't care.
   3, noteName is typically not empty, and many games rely on this, especially when making use of extensions.
   Perhaps use a more strict mode by default, and have an option for a more lax mode (for salvaging repairable data).

headerCheck:

1. Certain bits in the data must be set to avoid some errors (Pak is full, etc). However, headerCheck validates checksums without setting it. These bits should be fixed if they are not set, to be more robust.

See wiki entry

[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.