Add more VRAM constants

[ISSOtm]

Tile block addresses as per the consensus thus far in #84, and also some attrmap addresses because I remember being confused as to their locations, and I think that:

SECTION "...", VRAM[ATTRMAP0],BANK[1] ; ...is more intuitive than...
SECTION "...", VRAM[TILEMAP0],BANK[1]

...and we already have some “spatially redundant but semantically distinct” duplicates anyway.

(Resolves #84.)

[avivace]

I'd suggest picking up the conversation from #18 and challenge e.g. #18 (comment) which summed it up why at the time we were removing those.

Also, not strictly related, but please don't use ...and we already have some “spatially redundant but semantically distinct” duplicates anyway. as an argument to this. The existence of prior exceptions doesn't create a general license. Those may have been ad-hoc exceptions, things that are just waiting to be worked on, or simply... debt (and we don't want debt, let alone self-reinforcing debt)

[Rangi42]

@avivace Re: the conversation in #18, I addressed that in the issue #84 discussion. (I wasn't expecting a PR to exist this soon.)

Re: the unrelated ATTRMAP0-1 constants this PR invented, I think they're consistent with how we've been doing things lately.

We've already cleaned up almost all "debt" by moving old constants to hardware_compat.inc or removing them entirely. (And the remaining debt, postponed for v6.0, has been small oversights like #64, not any constants we still want to remove.)

The "spatially redundant but semantically distinct" constants we still have are recent ones:

• JOYP_START vs JOYP_DOWN (two different uses of the same bit, controlled by JOYP_GET)
• AUD1LEN_DUTY vs AUD2LEN_DUTY (two different registers with identical bit patterns)
• LCDC_BG vs LCDC_PRIO (bit meaning changes in DMG vs CGB)
• rBMODE vs rRTCLATCH (address meaning changes in MBC1 vs MBC3)
• BG_YFLIP vs OAM_YFLIP (two different entities with identical bit patterns)
• TILE_WIDTH vs TILE_HEIGHT (tiles are 8x8px, and I originally argued in favor of one constant for the side length, but it was agreed that these two names made more sense)
• etc

My impression is that by now these aren't "ad-hoc exceptions", but are our accepted standard method for how to deal with semantic ambiguity. (It's basically the same principle as having two constants B_LCDC_BLOCKS and B_IE_JOYPAD for the same number 4.)

[ISSOtm]

Merging this PR due to lack of negative feedback in the last three months, and positive demand (#84 (comment)).

[Rangi42]

Merging this PR due to lack of negative feedback in the last three months, and positive demand.

The last commit to this PR was just today (the TILES_PER_BLOCK constant).

I approve of it as-is, and am waiting for @avivace to review this and the other recent PRs.