Address issue #1078 (Inaccurate function names)

[xCrystal]

The most generic label renaming changes are in the first two commits (first commit related to my first issue comment, second commit related to my more recent issue comment), but some more specific changes are each in their own separate commit for visibility.

I'll point out just the changes that can't be derived from the comments in issue #1078:

• Fade in/out function names use the suggestions from mid-kid.
• PlaceHLTextAtBC has been renamed to PrintTextboxTextAt (5be9856)
• SetPalettes has been renamed to SetDefaultBGPAndOBP.
• HDMATransfer and HDMATransferTilemapAndAttrmap function names use the suggestions from mid-kid.
• LoadOverworldTilemap, LoadOverworldAttrmapPals, and LoadOverworldTilemapAndAttrmapPals for the respective functions (changing Screen to Overworld from the initial proposal in the first issue comment)
• wVramState renamed to wStateFlags in addition to adding flag constants (f72f078)
• refreshscreen -> reanchormap, and reloadmappart -> refreshmap (7f3b879)
• wScriptFlags2 has been renamed to wEnabledPlayerEvents (because it only apples to events within PlayerEvents), and the names of the functions that set/reset/check bits from it have been consolidated.
• For the attribute flag changes in 0266f64, the renaming is just in hardware_constants.asm. The other changes are just applying the new names.

[mid-kid]

Thanks a lot for the pull request! And sorry, I just noticed it now, it's been a busy few weeks for me. Don't be afraid to ping us on the discord if we take too long. Clear and concise commits that can be reviewed individually, it's gonna be fun to review.

First comment off the bat: I'd rather not modify hardware_constants.asm in such a repo-wide manner unless it's to realign with https://github.com/gbdev/hardware.inc/blob/master/hardware.inc (which would be great to switch to in the future). If a constant is used for two separate purposes, I'd rather have two constants than one (hardware.inc does this, too).

[xCrystal]

First comment off the bat: I'd rather not modify hardware_constants.asm in such a repo-wide manner unless it's to realign with https://github.com/gbdev/hardware.inc/blob/master/hardware.inc (which would be great to switch to in the future). If a constant is used for two separate purposes, I'd rather have two constants than one (hardware.inc does this, too).

Didn't even think of hardware.inc actually. Now I'm surprised that I'm only finding OAM attr constants and not BG Map attr constants there, but most likely there is a sensible reason for it that I'm not aware of.

I can get rid of the commit addressing this for now, I just found it weird that OAM_* flags where being used in the context of BG Map tiles as well.

[mid-kid]

No, it's a good commit, but I will request you consider splitting it into a new PR if you feel like it. That way, we can discuss the situation regarding the lack of BG map attribute constants with the hardware.inc upstream. I figure it's mostly an oversight - most homebrew relies on tools to generate BG maps, instead of specifying attributes in the source like we do.

[xCrystal]

No, it's a good commit, but I will request you consider splitting it into a new PR if you feel like it. That way, we can discuss the situation regarding the lack of BG map attribute constants with the hardware.inc upstream. I figure it's mostly an oversight - most homebrew relies on tools to generate BG maps, instead of specifying attributes in the source like we do.

Sounds good. Moved that commit elsewhere and applied all other suggestions in 17d3a1a. Thanks!