Show the crafting machine in crafting option tooltips

[rubensworks]

Closes #181

Hovering a craftable in the storage terminal now says which machine it is crafted in, by name and by icon, below the crafting requirements.

Iron Ingot
Quantity: 1
Crafting Requirements:
[raw iron]
Crafted In: Furnace
[furnace]

When several distinct machines expose the same recipe, the label drops the name and the icons speak for themselves (Crafted In: followed by one icon per machine). Interfaces targeting the same machine type are shown once.

How it works

The machines are resolved server-side in TerminalStorageTabIngredientCraftingHandlerCraftingNetwork, once per channel, from ICraftingNetwork#getRecipeCraftingInterfaces and ICraftingInterface#getTargetMachineItem(). Each interface's machine is resolved at most once per call, since many recipes are commonly exposed by the same interface. They are serialized alongside the recipe and carried to the client on the crafting option, exposed generically through ITerminalCraftingOption#getCraftingMachines() (defaulting to empty, so handlers that cannot determine them are unaffected and write nothing).

To give the machines and the requirements each their own labelled icon grid, tooltips are now built as a List<Either<FormattedText, TooltipComponent>> that mixes text and visual components, rather than a list of lines plus a single trailing component. That changes the last parameter of IIngredientComponentTerminalStorageHandler#drawInstance; the shared slot-grid rendering moved into a ClientCraftingOptionSlotsTooltip base class that both grids extend.

Downstream implementors

IIngredientComponentTerminalStorageHandler is implemented outside this repo by Integrated Mekanism. CyclopsMC/IntegratedMekanism#29 follows this signature and should be merged and released after this PR.

Note that Integrated Mekanism is already broken against Integrated Terminals 1.9.0, independently of this PR: #210 made the TooltipComponent variant of drawInstance the abstract method, which Integrated Mekanism never implemented, so chemicals throw an AbstractMethodError for craftables and crafting job outputs. CyclopsMC/IntegratedMekanism#28 fixes that on its own and can be merged now.

Dependency bumps

ICraftingInterface#getTargetMachineItem() was added in CyclopsMC/IntegratedCrafting#225 and first published in Integrated Crafting 1.6.0-715, which this now pins.

That build requires newer CyclopsCore and CommonCapabilities than were pinned here, so those move to the versions Integrated Crafting itself builds against:

	before	after
integratedcrafting_version	1.5.0-689	1.6.0-715
cyclopscore_version	1.26.2-808	1.29.3-1096
commoncapabilities_version	2.9.12-263	2.11.5-363

integrateddynamics_version and integratedtunnels_version already matched Integrated Crafting's and are unchanged.

Testing

New game tests in GameTestTerminalCraftingOptionMachines: serialization round-trip (with and without machines), machine resolution from a live network for the regular and the attuned crafting interface against a crafting table and a furnace, and deduplication across two interfaces on the same machine type.

All 47 required tests passed :)

./gradlew build and ./gradlew runGameTestServer both pass against the released Integrated Crafting build, on this branch rebased onto 1a98691.

Verified in a dev client with clientdevbridge-cli, for the regular and the attuned crafting interface against a crafting table and a furnace, plus the multiple-machine case.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RM86uiqD4soLkMyjC9Eeid