Feature: Allow API users to set ResourcePackOption's, add a GeyserDefineResourcePacksEvent

[onebeastchris]

This PR adds quite a bit of resource pack related API, and changes how resource packs are handled.

New: ResourcePackOption's
A system to pass options alongside/for a resource pack, that define how these are sent to the client. Currently implemented:

• PriorityOption : the order in which resource packs are applied on the client, thereby allowing api users to change the order in which packs override each other. This is done with a double between 0 and 10 inclusive, which are then sorted.
• SubpackOption : allows specifying a Subpack of a resource pack. (Implements Resource Subpack Loading #4939)
• UrlFallbackOption : Only relevant for packs provided via the new UrlPackCodec; allows to disconnect the player instead of providing the pack over raknet. This could be interesting for cases where the resource pack link isn't working anymore

New event:

• GeyserDefineResourcePacksEvent: similar to the SessionLoadResourcePacksEvent, this event allows registering ResourcePack's to the core Geyser resource pack registry. With this, the GeyserLoadResourcePacksEvent api will be deprecated, and marked for removal.

New api methods for the SessionLoadResourcePacksEvent and GeyserDefineResourcePacksEvent:
#register(ResourcePack, ResourcePackOptions<?>...): Registers a resource pack with these resource pack options.
#registerOptions(UUID uuid, ResourcePackOption<?>... ); Registers options for an already registered resource pack.
Collection<ResourcePackOption<?>> #options(UUID); Returns a collection of all set resource pack options for a registered resource pack.
@Nullable ResourcePackOption<?> #option(UUID, ResourcePackOption.Type) - returns an option with the specific type currently applied to a resource pack

New addition to the ResourcePack: a ResourcePack.Builder

• Can be used to provide a content key. Without it, there is no ideal way to add a content key to url codecs (either requiring new methods to create a url pack codec with a url and contentkey, or moving it elsewhere and risking it to be modifiable).
  ...and a ResourcePack#uuid shortcut to avoid getting the manifest, then header, and finally the UUID.

ResourcePackManifest additions:

• Subpacks, Settings: https://github.com/GeyserMC/PackConverter/blob/master/pack-schema/bedrock/src/main/java/org/geysermc/pack/bedrock/resource/manifest/Subpacks.java

API Deprecations:

• the PackCodec#serialize() method takes in a ResourcePack parameter which isn't used. It's also not relevant as a codec would represent a singular resource pack. This method was deprecated, and replaced with a serialize method without a parameter.

Further, this PR (currently) supersedes #4205 by also including the changes made there here. This is done to ensure that the options system plays nicely with the changes there; but i can split it up again if that's desired.

Brief rundown of changes in the remote resource pack PR:

• Addition of a UrlPackCodec that can be used to create a resource pack from a URL. Geyser will download the pack there to get a manifest, and provided that the UrlFallbackOption is not disabled, also provide the resource pack over raknet as a fallback when the client fails to download it from the url.
  However, in order to not have to wait until configurate auto-adds config options, i've not included the remote-resource-packs config option here, making url packs api only. That, imo, is also fine given the overly complex requirements of url packs (content type, size, etc)

Internal changes:

• The resource pack registry holds UUID keys now, and a ResourcePackHolder to hold default resource pack options - provided in the GeyserDefineResourcePacks event - and the resource pack itself.
• Much of the resource pack logic has been moved into the Geyser impl of the SessionLoadResourcePacksEvent - this makes sense imo as it avoids cluttering the UpstreamPacketHandler, and also ensures that the options are set from the same spot they're collected from.
• Addition of a OptionHolder which holds the various ResourcePackOption's. The use of it would be to avoid duplicate types, to validate options - e.g. not allowing a subpack option if there are no subpacks on a given pack - and to provide both default resource pack options (set in the define event) additionally to the options in the session event, while avoiding duplicate keys.
• Some validation on the resource packs requested by the client: Disconnecting if a requested resource pack wasn't part of the originally sent packs, or if the uuid has been tampered with.

Opening as a draft now until it's decided whether we want to actually implement such a system, or whether we want to split this into multiple PR's.