Add SLMP (MELSEC Communication 3E) protocol module (read-only wire layer)

[LivingLikeKrillin]

First increment of the SLMP driver proposed in #2585 — the codegen-layer protocol module only (protocols/slmp), opened as a draft per the Slack suggestion so the work is visible early.

What''s in it

• 3E binary frame (request/response discriminated on the subheader byte), little-endian, read-only
• Commands: Batch Read (0x0401), Random Read (0x0403), Batch Read Multiple Blocks (0x0406), word units
• Root type declares the new-SPI encoding defaults
• ParserSerializer vectors derived from the worked examples in the public Mitsubishi reference manual SH-080008 (sections 8.1 / 8.3 / 8.4)

Validation so far

• mvn -pl protocols/slmp test green on current develop (post-SPI3 merge): the mspec parses and all type references resolve
• 0x0401 / 0x0403 cross-checked against pymcprotocol (independent MIT-licensed client): its request bytes are byte-identical to the vectors except the monitoring-timer field, and it decodes the responses to the manual''s exact values
• 0x0406: pymcprotocol has no multi-block API, so the request vector rests on the manual''s worked example plus an independent re-encode check — flagging this honestly
• The ParserSerializer suite is not yet executed by any build module — like the other protocols, it runs from the (upcoming) driver module; until then the in-module test validates that the mspec parses and all type references resolve
• Byte round-trip through generated code will come with the driver module

Next (not in this PR)

• plc4j/drivers/slmp on the new SPI (slmp-tcp; single in-flight request since the 3E frame has no serial number)
• Bit units, more devices, write commands, ASCII mode, 4E — per the staged roadmap in Contribution proposal: read-only SLMP (MELSEC-Communication 3E) driver #2585

---

Developed with AI assistance; every wire-layer byte was verified against SH-080008, with the batch and random reads additionally cross-checked against pymcprotocol as noted above.