Add type to represent unimplemented data component types

[TonytheMacaroni]

Adds an Unimplemented type for data component types that have yet to receive an API implementation. This replaces using DataComponentType.NonValued for such cases. Using DataComponentType.NonValued here causes issues as you're able to get instances of unimplemented data component types using methods like Registry#get and ItemStack#getDataTypes.

Tested with ItemStack#hasData, ItemStack#resetData, and ItemStack#unsetData.

Not a big fan of using raw types for the converters, but unsure of a better way to do it.

[ShaneBeee]

Call me crazy, but do you think it might be a good idea to add the unimplemented types to DataComponentTypes?
With a note saying they're currently not supported by the API?
This could cut down on people asking "Where is X component, I saw it on McWiki?"

ex:

/**
* Not Currently Implemented
*/
@Deprecated (or some other annotation)
static final DataComponentType.Unimplemented CUSTOM_DATA;

[TonytheMacaroni]

That was originally something I wanted to do (although just using DataComponentType as the field's type, instead of a new API interface), but changing the types of fields breaks compatibility unconditionally.

I guess data components are already generally marked as 'unstable', but I don't think it's worth it to add the fields anyway.

[Owen1212055]

Backward compatibility with the fields is never guaranteed, FYI.

However this is defo a tricky part of the API, so most likely more feedback will need to be collected here.

[lynxplay]

I'd rather not expose un-implemented types to the API fields.

Having something actively exposed that does not work seem pretty unintuitive for people.
"Thing not existing" seems a lot more clear that it just isn't API exposed.
I am happy with the unimplemented part.

[GliczDev]

I think something like isUnimplemented() or isSupported() exposed in the API would be nice to detect if the component is supported after getting it from registry or something

[TonytheMacaroni]

Not sure if that'd be particularly useful, especially since most of the time you'd have something like:

DataComponentType type = ...;
switch (type) {
    case DataComponentType.Valued<?> valued -> ...;
    case DataComponentType.NonValued nonValued -> ...;
    case DataComponentType unimplemented -> ...;
}