RedCraftChat 0.2.1-SNAPSHOT

Let Bedrock use the dialogs, and delete the Cumulus copies

The Bedrock forms existed because I concluded Bedrock could not render a
dialog. That was wrong, and generalised from a real finding about chat:
Geyser does strip click and hover from chat components, but dialogs
travel a different packet path with a dedicated translator. Geyser
2.11.2 has JavaShowDialogGameTranslator, builds a CustomForm or a
SimpleForm from the dialog depending on whether it carries inputs,
handles text, boolean, single-option and number-range inputs, and sends
ServerboundCustomClickActionPacket back, which is the packet
DialogClickListener already reads. MultiActionDialog, the type sent
here, extends the class that does the form building.

The dialog appeared to do nothing on Bedrock at the time, which seemed
to confirm it. That was two bugs fixed since: pause set alongside
DialogAction.NONE, which rendered nothing, and an input key the client
rejected, which kicked it. Both broke Java too.

So the parallel implementation goes, along with the Floodgate dependency
that only it used. One definition per screen means the two can no longer
drift, which they did repeatedly: the recipient labels, the reply
wording, the arrival dates and the sent-to separator each had to be
applied twice.

Bedrock is still kept off the in-world panel. That is display entities
driven by interaction packets, a different question, and unverified.
Below the dialog it now falls to chat rather than to the panel.

Routing decisions are logged with their inputs, because a route on its
own never says which capability reported what.