Add OpenComputers drivers for Create's pulley, piston, and bearing blocks

[AdamDeBeers]

What

Adds OC drivers for five vanilla Create blocks with direct block-adjacent Adapter attachment: Elevator Pulley, Mechanical Bearing, Rope Pulley, Hose Pulley, and Mechanical Piston.

Why

No existing OC support for any of these blocks — they were only reachable indirectly via Create: Crafts & Additions' Digital Adapter as CC:Tweaked peripherals, with no OC equivalent.

Implementation

Five separate CreateEnvironment<T> classes in a new file, CreateContraptionEnvironments.java, each matched on its concrete block-entity type via CreateBlockDriver<> in CreateDrivers.java — the same pattern already used for the existing Create_Speedometer/Create_Stressometer/etc. drivers.

Class hierarchy note, confirmed via direct bytecode inspection of the Create 6.0.10 jar: ElevatorPulleyBlockEntity extends PulleyBlockEntity (the Rope Pulley's own class). A driver matched naively on PulleyBlockEntity would therefore also fire on actual elevator pulleys via instanceof, producing a redundant Create_RopePulley alongside Create_ElevatorPulley on the same block. The RopePulley driver is registered with a predicate excluding ElevatorPulleyBlockEntity instances (mirroring the existing Packager/RepackagerBlockEntity exclusion pattern already in this file) to avoid that.

MechanicalPistonBlockEntity is a sibling of PulleyBlockEntity under a shared LinearActuatorBlockEntity parent (explains why both expose getInterpolatedOffset), while HosePulleyBlockEntity extends KineticBlockEntity directly — an unrelated branch. Kept as three separate driver classes rather than one shared driver: the blocks are genuinely distinct, and only their single offset-reading method happens to share a signature.

Sticky piston note: Sticky Mechanical Piston and regular Mechanical Piston share the exact same MechanicalPistonBlockEntity class — confirmed via bytecode inspection of AllBlocks/AllBlockEntityTypes, both variants are BlockEntry<MechanicalPistonBlock> sharing one block-entity type. The sticky/regular distinction lives on the registered Block instance (create:sticky_mechanical_piston vs. create:mechanical_piston), not the block entity, so isSticky() reads it via Create's own MechanicalPistonBlock.isStickyPiston(BlockState) helper rather than needing a second driver class.

Exposed methods

All read-only except gotoElevatorFloor:

• Create_ElevatorPulley: getPulleyDistance(), getElevatorFloor(), getElevatorFloors(), getElevatorFloorName(index), hasElevatorArrived(), gotoElevatorFloor(index) (mutating — moves the elevator, returns the change in target Y)
• Create_MechanicalBearing: getBearingAngle()
• Create_RopePulley: getPulleyDistance()
• Create_HosePulley: getPulleyDistance()
• Create_MechanicalPiston: getPistonDistance(), isSticky()

Testing

Tested locally against NeoForge 1.21.1 + Create + a locally built opencomputers-1.9.4-dev.local jar from this branch. Confirmed:

• All getters live-update correctly in-game (elevator floor tracking, bearing angle, pulley/piston offsets).
• gotoElevatorFloor correctly moves the elevator and returns the target-Y delta.
• isSticky() returns true on a sticky mechanical piston and false on a regular one, verified with both idle/retracted (Create swaps in a different block entity mid-animation, same as vanilla pistons, so idle state was required for a meaningful test).

[AdamDeBeers]

Closing per the CONTRIBUTING.md guidance - same reasoning as #55, this belongs upstream in Create rather than here.

[RobertCochran]

Class hierarchy note, confirmed via direct bytecode inspection of the Create 6.0.10 jar: ...
(emphasis mine)

That is a weird thing for you to have chosen to do? I feel like it would have been easier for you to have searched through the source code instead of groveling through bytecode. Did you accidentally forget to disclose any use of AI used in this PR (not required at the time of submission, but would have been an appreciated courtesy)?

[AdamDeBeers]

Used a decompiler against the compiled Create jar since I didn't have mapped/deobfuscated source for that class handy - standard when working against a compiled dependency rather than a source checkout. The class hierarchy finding held up either way. Hello there. I just gave up. Have a great day.

[RobertCochran]

Sorry, I don't quite understand? This is useful work to include because Create is one of the mods that we do provide direct driver support for, as one of the few exceptions to the guidelines about drivers for other mods not living in the OpenComputers mod.

[AdamDeBeers]

Sorry, that came out confusing - I've never really contributed on GitHub before and worded that badly. The "gave up" part wasn't about this PR, it was frustration bleeding through from nearly a week spent fixing what I fixed here. Didn't mean to imply anything about the work itself. Reopening - thanks for clarifying Create is a supported exception.

[RobertCochran]

Ah, your comment was amended to clarify the bytecode groveling. My apologies on that front; I've been accused of using AI when I didn't at all and also found it deeply frustrating. It's a fine line to walk trying to suss out whether something is or isn't AI-generated when you're not sure. >.<

[AdamDeBeers]

No worries, appreciate you being straight up about it. Working on something with this that hasn't really been done in Minecraft before - can't say more yet, but the fork's public if you're ever curious how deep the rabbit hole goes. 🐰