Changes

Cleanup throws declarations on loadable

Moved them to the Javadocs so they are not automatically added to every override, the goal is just to tell the implementer what exception is expected there.

Add typed maps

Have in a few places needed a map where the values are typed based on a key, will need it for something in Mantle soon so including as a utility.

Implement LoadableRecipeSerializer

To minimize additional boilerplate, I opted to add a context to record loadables where additional data can be passed to the root record.
LoadableField now has a superclass RecordField, which has context aware methods. Idea here being LoadableField works when there is no context (and has impls passing in empty context), while RecordField is only usable in a record builder.
LoadableRecord got context parameters, but still has the method headers with no context for IGenericLoader and non-loadable usage compact. They just pass in empty, which means context does not currently propigate to nested loaders unless you use a direct field. I don't think there is any justification for including context in all loader usage unless I start including other stuff in context.
ContextKey allows creating keys for said data, by default there are two - the recipe ID, and the recipe serializer.
In addition AbstractRecipeBuilder has a finished recipe using loadables
Finally, added TypeAwareRecipeSerializer for the sake of recipes that use the serializer to swap types, lets them reuse a loadable instance.

Make collection loadable error during datagen if given too many elements

We never want to datagen a combination that is illegal to parse, defeats the whole purpose of datagen
Does not currently validate network in the same way, partly as if you got that far you should be valid, partly as a vew casees with custom networking can get weird behavior, like empty tags syncing as an empty set

Implement EitherLoadable

This is designed for things like FluidIngredient and EntityIngredient that have multiple forms controlled by subclasses. USing this let me much simplify the impl for both getting loadables
I did not use it for ItemOutput as that one wants 4 different loadable variants, which conflicts with how the either internals work. Only way to deal with this breaks the datagen only ingredients so I figured I'd stick with what works.

Implement SizedIngredient loadable

Uses new TryDirectField, like DirectField but for a loadable that is not strictly an object, only saves into the object if its safe to do so

Fix reading item stacks from network reading with size 0 if count is unspecified

Holdover from when I supported fixed sizes of values besides 1

Expand debug info on logging recipe serializer

On serialization, print the recipe ID, type, and class. On deserialization, print the recipe ID, and in loadable serializers print the type (if type aware) and the loadable. Makes it easier ot identify which recipe is failing.

Rename FriendlyByteBuffer methods on Loadable to match StreamCodec

Saves me from doing a refactor later making it less effort for addons to update that directly call the methods.
As part of implementation, created Streamable, which is a less generic version of StreamCodec. I would just use StreamCodec but it has the minor issue of not existing.
EitherLoadable now uses streamable instead of loadable for its network logic as that makes it easier to implement a custom variant.
GenericLoaderRegistry and GenericNamedComponent both have their methods updated to the new name with the old ones kept around as deprecated.
This commit also marks the deprecation of IGenericLoader, come 1.20 I'll be making GenericLoaderRegistry a registry of RecordLoadable.

Add a custom nullable field implementation to NamedComponentRegistry

Since its got its own optional byte buffer methods, might as well support it