feature: json component serializer

[kezz]

This PR adds a new module providing an implementation agnostic JSON serializer. The intention behind this PR is to allow platforms to swap between or use alternative implementations of a json serializer (see #839) whilst still allowing consumers of the platform to work regardless of the backing impl.

work that needs doing:

• [x] decide whether we need to bother with legacy stuff (legacy nbt serializer too?)
• [x] common tests for other serializers to use
• [x] common jmh benchmarks for other serializers to use
• [x] better error message for missing impl
• [x] docs for this (also in javadocs)
• [x] common builder for JSON serializers
• [x] finish moving text-serializer-gson-legacy-impl out to a json version, remove the old one from the bom, and stop publishing it with 4.15.0 (anyone still using it can just depend on an old version)
• [ ] do we want a common flavour of the Provider services that normal serializers have, intended to be implemented by platforms? not worth doing in this first revision

[zml2008]

I think it's worthwhile to port the LegacyHoverEventSerializer and text-serializer-gson-legacy-impl over to JsonComponentSerializer -- it doesn't have any direct gson deps.

With options, I think it's worthwhile to have a common builder interface exposed as well -- since there are a few configurable elements.

I'm not sure what your goals were with the Fallback interface were -- I don't see it having any practical effect since you already orElse to the fallback without needing service discovery.