Implement RT_ISG & RT_HOVERING

[Pepe20129]

This is definitely not done yet, before merging we need to decide a few things:

• Do we split RT_HOVERING like the old 3ds rando code did?
• Do we check if there's an "ISG source" in the helper method itself instead of leaving it to users of the method? If so, how?
• Are there more considerations for hovering logic?
• How do we handle gs tokens that are over a slippery slope (eg, sfm)?
• How do we clarify which hovers are and aren't part of the trick in its description (eg, hover past shadow boat is not included)?
• How do we handle ISG in enemy kill logic?
• Did I miss any hovers in this first pass?
• Are there any other logical implications of ISG?

Build Artifacts

• soh-windows.zip
• soh-mac.zip
• soh-linux.zip

[serprex]

This seems pretty widespread, skips many entrances. Updating those will be better after dungeon refactors. But in terms of general glitch tricks adding something like "Light Torches with QPA" would have a much smaller scope

[Pepper0ni]

Hovers should absolutely be split into difficulty, though I'm not sure how to separate things, would need to talk to people.

For ISG availability, Is there anywhere it's not available from Navi?

[inspectredc]

For ISG availability, Is there anywhere it's not available from Navi?

Dungeons would be the main place

[Pepe20129]

I don't think there's an easy way to check for being able to interrupt the crouchstab in dungeons without enemies.
It's not currently a problem as the only logical use of ISG inside a dungeon is biri hover.