NES: Improve OAM corruption accuracy.

[Fiskbit]

Our understanding of OAM row corruption has significantly improved since Mesen's implementation of the feature that was based on oam_flicker_test.nes results. This change improves the accuracy of the two OAM corruption emulation options.

Primary OAM (OAM1) and secondary OAM (OAM2) live in the same block of memory, made up of 9-byte rows where the first 8 bytes are consecutive OAM1 bytes and the last byte is an OAM2 byte. The PPU accesses OAM on every dot. On some dots, it uses the OAM1 address ($2003), and on other dots, it uses its internal OAM2 address. If the address changes during an OAM access (the 2nd half of a dot) and this causes the selected row to change, then it can trigger either analog corruption (the new row gets 'random' data) or a row copy (the old row's 9 bytes are copied to the new row). More information can be found at nesdev.org/wiki/OAM_internals.

Address selection is fairly simple. When rendering is off, OAM1ADDR is always selected. When rendering is on, OAM1ADDR is selected on odd dots in 1-256, and otherwise OAM2ADDR is selected.

Corruption occurs on the NES in 3 situations:

1. Writing to $2003 on NTSC PPUs, because writes are not synchronized at all and so the CPU open bus value and the new value can both cause the row to change mid-access. Depending on the timing, this can do nothing, cause analog corruption, or cause row copy. This was fixed in PAL PPUs, but we don't know about Dendy.
2. Toggling rendering on an OAM2ADDR dot. Depending on the direction and the timing, this can do nothing or cause analog corruption of or row copy to the new row.
3. On 2C02E and later PPUs, having a row mismatch if rendering is enabled at the start of pre-render. This always causes a row copy from the OAM1ADDR row to the OAM2ADDR row and is required for Huge Insect to spawn enemies in level 1. (2C02C PPUs have some corruption in this situation, too, but it is not yet understood.)

This change adds support for OAM corruption in situations 1 and 2 using the "Enable PPU $2003/rendering-toggle OAM corruption" setting, which is off by default. This does not take alignment into account at all and only does row copy, not analog corruption. Recommended for developers, but probably undesirable for actual users. This setting was previously called "Enable PPU OAM row corruption emulation". Note that situation 1 ($2003 writes) is not perfectly matching blargg's oam_read test results in the most vulnerable alignment yet, suggesting there is more research to be done on this.

Situation 3 is now supported under the "Disable PPU frame-start OAM corruption (2C02D and earlier)" setting, so this corruption happens by default. Mesen was already doing some corruption here to support Huge Insect, with the previous version of this setting being called "Disable PPU OAMADDR bug emulation". These changes make the corruption more accurate and apply in more situations, so there is a chance it will break some user software, but because it is required for a game, we've opted to have it on by default. This feature should match hardware very closely, as it doesn't have the timing and analog aspects seen in situations 1 and 2.

To support these, sprite rendering was reworked a bit to more accurately manage the OAM1 and OAM2 addresses during rendering. This should make sprite rendering behavior more accurate when rendering is toggled mid-frame, although there are still inaccuracies that come up if you do this. The OAM2 address can also now be seen in the register viewer below $2003.

This was tested against a suite of NES tests, AccuracyCoin $2004 Stress Test, and oam_flicker_test.nes/oam_flicker_test_reenable.nes. The $2003-based corruption causes a few tests to change behavior when enabled (which is expected), but oam_read and related tests are not failing exactly right yet. Tests otherwise pass.

[Fiskbit]

100th Coin did some testing and agrees that this appears to be corrupting OAM correctly (in the non-$2003 case). I also did some testing with a homebrew game that is triggering corruption on hardware and what I see with my changes matches it (and behaves how I expect it to). 100th Coin noted that corruption timing isn't quite right, which is something I've noticed, too; it seems to be off by a dot or so. This is the same as in Mesen2 and I'm not exactly sure what's causing it, but it's out of scope for this PR.

[NovaSquirrel]

Code structure looks good and the games I tried seem fine with and without the checkbox. I appreciate all the comments explaining the choices made in the code.