Make random events more robust

What has been done in this MR?

• Ported some of the guts of the surprise exam random event over to ContentAPI, which causes it to correctly clean up its original-loc attribute. Fixes #1974.
• Removed the logout listener that kicks you out of the exam random if you log out. I could not find a source that logging out should cause you to get away from the random, whereas searching around https://www.google.com/search?q=runescape+%22stuck+in%22+%22random+event%22+site%3Awww.reddit.com suggests that all randoms should keep you trapped inside until you complete them, i.e. that relogging is not a valid escape. Fixes players staying teleblocked after they finish the exam.
• Made the random-event code robust to incorrectly missing original-loc attributes from the save file, as will happen when the save file is edited manually. This affects surprise_exam, drill_demon, freaky_forester, and evil_bob.
• Added a new zone flag, OFF_MAP, denoting whether the player is currently outside of the normal overworld (i.e. is inside a random or a POH). Added a tick action to check if the original-loc attribute is set erroneously while the player is not actually off-map; this fires a warning if so and then cleans up the erroneous attribute.

What should testers check?

• Pay especial attention to testing surprise_exam. Test that when the random kidnaps you, you get returned back to the correct original spot. Especially consider relogging inside the event.
• Test that, especially considering relogging inside and/or after the event, gravestones drop where you are at that point, not at the original location the event had kidnapped you from.
• Test that drill_demon, freaky_forester, and evil_bob still work normally.
• Use admin powers to teleport to a different region (i.e. you must have seen the "Loading..." popup) while you're testing. Confirm that in this case, when you finish the random normally, you get teleported to Lumbridge rather than to your original location. This indicates that the original location was wiped successfully by the tick handling code (Lumbridge is the fallback location if none is set).
• Test that other areas that drop gravestones somewhere else continue to do so. (Are there any such areas? I thought Bork was one, but that doesn't actually seem to be the case - when test comes back online, I'll check if that's a bug that I need to report outside of this MR.)

• I have tested these changes thoroughly.
• I used the relevant Zaros tool for any JSON edits where possible, and have attached screenshots of any changes.