Add MonoMod ModInterop Exports

[RedFlames]

We need to create ModInterop Exports so that other mods don't need to rely on IL Hooks which could break arbitrarily (see v2.2.0 -> v2.2.1, issue with GravityHelper).

Resources:
https://github.com/MonoMod/MonoMod/blob/master/README-ModInterop.md
https://github.com/EverestAPI/Resources/wiki/Cross-Mod-Functionality#modinterop

I'm making this issue to figure out what Exports we can/should add and where, and later we can document it on the Wiki tab.

There's also event delegates that other mods can and do make use of 🤔

Status quo of some mods that hook into CelesteNet:

Gravity Helper

Adds delegates to CelesteNetClientContext.OnInit and CelesteNetClientContext.OnDispose for when CelesteNet gets "turned on/off". It uses these only to register DataType handlers from its class, specifically one for its own type DataPlayerGravity.

Adds IL Hooks into GhostNameTag.Render and GhostEmote.Update to change the world position Y offsets these get rendered at.

Other mods to look into

Madhunt (hi Popax)
HeartWars
Head2Head
GoldenQOL - opt dep - uses Reflection to check if chat is active to prevent activating its hotkeys
EmoteMod
Styline - opt dep
BrokemiaHelper - opt dep

Others?
KyaruMod for example doesn't even list CelesteNet as an opt dependency, neither does Guneline

Things mods might want to do

Module or Context level

• check if connected
• get the player name
• does Everest already provide a way to get other mods' settings?

Ghosts

• adjust rendering?

NameTags, Emotes

• adjust offsets
• change rendering in some way?

Chat component

• check if chat open
• event for new messages
• event for sending messages
• register local commands, once that becomes a feature
• register tab completions

Player List component

• check if open
• events for players joining/leaving
• add new columns on players if possible :thonk:

DataType handlers & filters

• does there need to be interop to register handlers

[RedFlames]

#174