QoL patch - allow replacing HM moves

[anzz1]

QoL patch - new key option: "Forget HM Moves": Allow replacing HM moves like regular moves (OFF by default)

Goes along well with the reusable TM improvement, to not have to use the move deleter npc if wanted to shuffle moves around in the overworld, also relieves the weight of HM decisions.

Hope I understood the padding thing on gSaveBlock1Ptr->keyFlags right (substracted 1 from padding field to make room for the new gSaveBlock1Ptr->keyFlags.forgetHM 0/1 flag)

TODO:

• (nitpick warning) I remember at least one NPC having a dialog entry which says something like "hm's cannot be forgotten easily", replace that dialog by something else if the flag is on.
• on "trapped in cinnabar" softlock logic, skip the check for "all 4 moves are HM moves, hence surf/fly cannot be taught" if "forget hm moves" is ON

[anzz1]

This shouldn't introduce any new softlock possibilities, since you could always re-teach the forgotten HM. Old softlocks (release/trade the HM poké) are unaffected. I cannot really figure out why the decision to make HM's permanent was made in the first place.

The new option was added under the "Exp. Modifier" key in the "Advanced Keys" section, with a help entry to match.

[anzz1]

Also, this isn't really the place to post this but cba to make a forum account for a single post, so here it goes:

From some googling around, if I understood correctly, in FRLG the enemy trainers have always 0 IV/EV by default. If that is the case (and maybe it's common knowledge too), the features/FAQ could be amended by adding this info for the newcomers. That setting EV keyflag to zero and IV flag to zero or perfect, levels the playing field against enemy trainers.

As a casual player I always disliked the EV system so this option to make them go 404 is a great addition.

[anzz1]

~~Yeah, I need to ofcourse replace the whole 16bit padding field with the new one to keep the struct size same. idk what I was thinking in my 1st commit, brain fart.~~

~~Is there a reason why you use 16-bit fields for the keysystem flags while u8 or u4 would suffice? I do not know a thing about GBA coding, is there some system related memory-alignment reason or something?~~

I had misunderstood how the compiler packs C structs (to bitfields) when using the colon ( : ) formatting, so I had it right in the first commit.