* Giant's Knife Behaviour Fixes
Fixes a case where Giant's Knife (specifically, breaking and re-buying it) can behave unexpectedly if you don't have a Kokiri Sword in your inventory. Also fixes the broken icon not showing up in inventory after you break it.
* less whitespace
* fix 0xE check
Accidentally committed with the wrong check
* Move the grayscale code up
Moved the grayscaling portion up higher in the function and renamed "bool not_acquired" to "bool age_restricted". Thanks to @vaguerant for the suggestion!
reported on discord, i don't have the ability to reproduce this, but it
appears to be a benign fix, as the only time that the tent2 is checked
down later is guarded by a null check.
Haven't removed where rando stores the hints for itself and the ganon and altar hints are still pulled from the randomizer class' local storage, but gossip stone hints are pulled from the custom message table now.
* prefix randomizer methods with Randomizer_
* make filename a local var
* remove unused file, update malon to use new names
* move randomizertypes to randomizer directory
* rename to Randomizer_GetSettingValue
Co-authored-by: briaguya <briaguya@alice>
Also auto-dissmisses the textbox when gSkulltulaFreeze is on. When gInjectSkulltulaCount is off, text is not auto-dismissed just like before, since that is base game text still.
Basically, some external code can choos a unique id and create a message table for itself. The idea is that modders can hook into this as well so they can get their own message table and don't have to worry about conflicting with the base game's textIDs. I have also implemented this setup for Randomizer so that the pre-filled bottles (which didn't exist in the original outside of Ruto's letter) have unique text as compared to the text for the item they are filled with.
`CustomMessage_RetrieveIfExists` is placed at the very beginning of the z_message_PAL.c `Message_OpenText` if statement after any special changes to textIds are made. This function will either return either true or false and if true it will populate the necessary values of font and msgCtx to display said message. It's placement at the beginning also allows for overriding existing textIds to have new information, which will come in handy later.
Pulls the Custom Message related code out into it's own class, which has an initialization phase where other enhancements / future features can create messages during an initialization phase to be stored and retrieved later. Along with this refactoring, the 4 bottle messages from the previous rando-specific system are now created and stored during intialization and retrieved by their getItemId.
Now that it isn't rando specific, the goal is to move anything text changes that are hard-coded into z_message_PAL.c and refactor it so that future text additions/overrides can be done without modifying that file.
