Data component cleanup

[Robotgiggle]

Various minor fixes and improvements to do with item components:

• fixes Ancient Cyphers not having the Ancient Pigment baked in (I think this just got lost in the port somehow)
• fixes the safety check on creative scrolls now that the ACTION component stores a ResourceKey rather than a ResourceLocation
• fixes a typo when setting the MEDIA and MAX_MEDIA components using ItemMediaHolder.withMedia()
• removes the now unused string constants that previously stored the names of the NBT tags used by casting items, media holders, and the media cube
• adds comments to HexDataComponents explaining where each component is used
• adds comments to ItemSpellbook to explain some of the more complicated if/else trees
• updates the comments in ItemScroll to refer to components rather than tags

[s5bug]

Would there be any value in making this a TreeList? I actually doubt it (I think it would need to be benchmarked) and converting on-use is going to be better than converting on-parse).

[Olfi01]

Wouldn't it be possible to make even alpha versions of items correctly readable by using Codecs?

[Robotgiggle]

How would you do that? The current alpha version uses two separate components, and the new version in this PR uses one component with two fields. I know you can make a codec that accepts input in multiple formats, but that’s still just expecting multiple formats within one data component. Is there some way to make a codec that can decode two separate components into a single object?

[Olfi01]

Right, sorry, that does sound like it might not be possible. What could be an option would be adding another datafixer, but I'll only be able to answer whether I think that's a good idea after I've finished doing it for the 1.20 -> 1.21 migration

[Olfi01]

After getting into it a bit, I think a datafix for alpha items should definitely be possible, the only question I'm having is how to get it to run since the vanilla process appears to be tied to save file versions and I'm pretty sure that's the same between before and after this commit.
Edit: Looking at it again, it seems to be possible to create a subversion for the schema, I'll fiddle around with that a bit to see if it's a viable option
Edit 2: No, just using the subversion still runs into the same issue that the versions are defined by MC and haven't actually changed during this commit

[Olfi01]

Looks good to me apart from the one @Nullable nitpick :D

[s5bug]

My personal opinion is that #1227 should be fixed as part of this PR. Don't know what that looks like yet, and my opinion could be "wrong" anyway.

I guess the change doesn't make sense wrt the rest of the stuff happening in the PR but it seems really weird for the TODO to change but no action to be taken.

[s5bug]

I have decided I am wrong