Registry Modification API

[Machine-Maker]

Adds two new "events" that PluginBootstrap can register to which enable modification and addition to both built-in and data-driven registries. This opens up tons of new possibilities for plugins to customize things with API that was previously only possible with nms/reflection.

Data-Driven: Types which are loaded purely from datapacks (custom and vanilla) Built-In: Loaded via source code, never read from a file

There are two events plugins can listen to, one is fired when an "entry" is about to be added to a registry, either a built-in or data-driven. This allows modification of the "entry" before it's registered. The second event is fired right before the registry is frozen (to prevent new additions). This is used to add completely new entries.

Demo

There are two "demonstration" apis added, one for ChatType and one for GameEvent. Just allows some very simply customization, more just to show how it works for both built-in and data-driven types.

---

### TODO
- [x] https://github.com/PaperMC/Paper/pull/8642
- [ ] https://github.com/PaperMC/Paper/pull/9009
- [ ] https://github.com/PaperMC/Paper/pull/9233
- [x] better naming (not attached to any of them)
- [x] add specific "event" types instead to allow for more context to be added to listeners
- [x] ~~add more registry api, like getOrThrow(), hasKey(), helper util methods like that.~~ will be handled in different pr
- [x] Either remove, or fully flesh out the two "demo" API this adds (added GameEvent)
- [x] Add registry keys for other already-existing registries from Registry.java
- [x] Move Paper plugin changes to Paper Plugins patch
- [x] Add exception handling to event fires
- [x] ~~Discuss any "removal" or "cancel addition" API~~ left for future possible API
- [x] Should static final RegistryKey be in the RegistryKey or should we separate them? Like BuiltInRegistries could have keys and instances and DataDrivenRegistries would just have keys. **No, they should all be in one file like vanilla has now with Registries.java**
- [ ] Discuss having the "builders" under a separate API policy as the types they apply to change very frequently.
- [x] move registry modification patch into Paper Registry API patch
- [ ] https://github.com/PaperMC/Paper/pull/9629
- [ ] https://github.com/PaperMC/Paper/pull/10154

[Machine-Maker]

Updated for 1.19.4 and moved the vibration level to the builder so that it can be changed. Also added a test to make sure the match the map that was previously used.

[Machine-Maker]

For the GameEvent builder, I decided to not make the vibration level configurable there. They are really 2 different systems, the vibration stuff and game events. Not all game events are listened to for vibrations, so I think a better solution is to use the game event bukkit events to change the level of certain game events.

I also reverted the change that changed all the static final fields in GameEvent to Reference because we are now going with code generation to generate a file full of keys for GameEvent for use with the registry mod api.

[Browsit]

Just pointing out https://github.com/PaperMC/Paper/pull/10154 in case the TODO item gets overlooked

[Amejonah1200]

🥳❔

[lynxplay]

Merged into preliminary 1.21 registry dev branch