Add MBC registers, combined PAD masks, and color bits

[Rangi42]

Update the HISTORY.md date before merging!

• Fixes Define all registers for all MBCs #62: Defines MBC register constants
  • This is the first part of the file to include a middle layer of headings (the ; ** per-MBC headings, grouping the usual ; -- per-register ones).
• Fixes Define color channel offsets #61: Defines color channel offset bits
• Fixes Define combined button masks #60: Defines combined button nybble masks
• Fixes Incorrect comment(s) #59: Corrects a comment from 5.0

These are all new constants; nothing has been changed, deprecated, or removed.

[Rangi42]

The 5.0 PR #58 was merged rather abruptly, so if anyone has suggestions for what to change/add/remove in it, this can be a good place for them.

[Rangi42]

I considered adding an MBC3-only def rRTCVAL equ $4000, but decided against it for a few reasons:

1. MBC3 does use def rRAMB equ $4000 for RAM banking, so rRTCVAL would be an arguably redundant alias.
2. We already define RAMB_-prefixed constants for the RTC-related values (e.g. def RAMB_RTC_S equ $08 for RTC seconds).
3. I felt like more register names would be more confusing than keeping them grouped like this.

[Rangi42]

Regarding the suggestion to use conditional if defs to change the values of certain register names depending on the desired MBC -- I don't think that's necessary, and would overcomplicate the file.

Some MBCs have unique registers, like MBC3's RTC latch or MBC7's accelerometer data, which are harmless to define for everyone. (Read the comments or Pan Docs to see which registers are applicable to which MBCs.)

Some registers also have unique features, like how MBC5's RAM bank register also controls Rumble, or MMM01's RAM enable register also controls its mapping mode. Again, we can just have MBC-specific mask or value constants that are always defined/available.

The only register name that can ever be, not just irrelevant, but wrong, is "ROMB" for the ROM bank number register. It's commonly $2000, but for MBC2 should be $2100 (or any value with bit 8 set, $0100, $0300, etc). Given the low actual need for MBC2 support, I think it's fine to just define an MBC2-specific "ROM2B" register, with the understanding to use it instead of ROMB. (Not "ROMB2", because that would look associated with MBC5's 9-bit ROMB0 + ROMB1.)

As for MBCs with unique registers that use certain addresses instead of their more common roles, those are harmless to always define, and are handled with comments:

; ** Common to most MBCs ******************************************************

; -- ROMB ($2000-$3FFF) -------------------------------------------------------
; ROM bank number (not for MBC5 or MBC6) [wo]
def rROMB equ $2000

; -- RAMB ($4000-$5FFF) -------------------------------------------------------
; SRAM bank number (not for MBC2, MBC6, or MBC7) [wo]
def rRAMB equ $4000

; ** MBC2 only ****************************************************************

; -- ROM2B ($0000-$3FFF) ------------------------------------------------------
; ROM bank number [wo]
def rROM2B equ $2100

; ** MBC5 only ****************************************************************

; -- ROMB0 ($2000-$3FFF) ------------------------------------------------------
; ROM bank number low byte (bits 0-7) [wo]
def rROMB0 equ $2000

; ** MBC6 only ****************************************************************

; -- ROMBA ($2000-$27FF) ------------------------------------------------------
; ROM/Flash bank A number [wo]
def rROMBA equ $2000

; ** MBC7 only ****************************************************************

; -- RAMREG ($4000-$5FFF) -----------------------------------------------------
; Enable RAM register access [wo]
def rRAMREG equ $4000