Refactor machine tool actions

[RecursivePineapple]

This PR refactors tool interactions with machines and removes the deprecated onXRightClicked methods. The actions for single block machines were cleaned & polished up but untouched functionality-wise. The actions for multiblocks were slightly rearranged. Several new onXRightClicked methods were added to IMetaTileEntity to support the various multi toggle buttons (hard hammer and jack hammer).

These are the main multiblock actions:

• When a screwdriver is used, the mode is changed (already existed, but improved)
• When a soldering iron is used, output voiding is toggled (new, migrated from gt++ & bartworksmultis)
• When wire cutters are used, batch mode is toggled (new, migrated from gt++ & bartworks multis)
• When a hard hammer is used, input separation is toggled (new, migrated from gt++ & bartworks multis)
• When a jack hammer is used, recipe locking is toggled (new, migrated from gt++ & bartworks multis)

Singleblock actions:

• When a hard hammer is used, allow input / allow output is toggled (existing, but its purpose was unclear - chat messages have been improved)
• When a screwdriver is used, input from output side is toggled (existing)
• When a soldering iron is used, multiple stacks will be allowed in (existing)
• When wire cutters are used, stack input filtering is toggled (existing, although I'm not sure why this exists - seems like it could break something)

Shared actions:

• Wrenches & soft hammers work the same
• Shift right clicking with wire cutters or a soldering iron will try to connect a neighbouring cable to the block (existing)
• Various idiosyncrasies around cover sides and wrenching sides when using tools

A lot of the changes are from removing the deprecated onXRightClicked methods. The return type of onScrewdriverRightClicked was changed to boolean to match the other right click methods.

Some machineMode code was cleaned up since a few multis relied on the default behaviour of nextMachineMode when they shouldn't have.

The chat messages for miner mode & radius changes (singleblock & multiblock) were also improved a bit.

[YannickMG]

How does this interact with hatches/buses which might have those features, like input separation?

Also, how discoverable are those interactions? If they're standardized we might want that info on the tooltips for the tools themselves.

[RecursivePineapple]

@YannickMG

How does this interact with hatches/buses which might have those features, like input separation?

This doesn't touch anything with the modes themselves, it only lets you toggle them. So input separation etc will behave the same. There are a few hatch-specific settings (sorting, 1 stack limiting, recipe map filtering) but I haven't touched those either.

Also, how discoverable are those interactions? If they're standardized we might want that info on the tooltips for the tools themselves.

The multi-specific logic is defined in the multi base class, so multis can override the methods to opt out. They're standardized enough, but it'd need a disclaimer that some multis might not support some tools. I'm going to add a quest for it since there are quite a few caveats.

[YannickMG]

By the way I had previously "hidden" some information on tool usage for single block in the tooltips for buttons on their UI, which was better than nothing but not great. That text would either need to be removed or be kept up to date: https://github.com/GTNewHorizons/GT5-Unofficial/pull/858/files#diff-0424401ca733037441e2d1b48951a5ae407801a53d4e84d2e87b8d65e51c3868

[RecursivePineapple]

Drafting this because I need to take another look at all the machines affected