[Feature Request]: Contribution proposal: read-only SLMP (MELSEC-Communication 3E) driver

Following up on #1728 (the answer there was essentially "no plans, but contributions welcome") — I'd like to build this.

I've previously implemented the MC protocol family in production — the 3E frame in both ASCII and binary codings — so the protocol itself is well-trodden ground for me; the genuinely new part for me is PLC4X's `mspec`/SPI conventions. I'd implement strictly from Mitsubishi's publicly available *MELSEC Communication Protocol Reference Manual* (SH-080008), which documents the 3E/4E frames, the device-code table, and the batch/random-read commands — so there's no dependency on member-restricted CLPA material.

To keep it reviewable, I'd start with a deliberately small **read-only** PoC and grow it in stages:

- **v0 (first PR):** 3E binary frame, read-only, Batch Read (`0x0401`, word units), `D` device, types INT/WORD/DINT/REAL, single request — plus a ParserSerializer test-suite so the wire layer is verifiable **without hardware**.
- **then, in stages:** more devices (W/R/M/X/Y/B) → bit units → Random Read (`0x0403`) with an optimizer (batch-vs-random selection, max-points splitting) → ASCII coding → 4E frame (serial-number correlation) / write / iQ-R extended addressing.

On naming and structure: I'd call the driver `slmp` (the open CLPA spec name, which covers the MC protocol — happy to switch to `mc`/`melsec` if you'd prefer), laid out mirroring the **modbus** driver: stateless TCP request/response, a `base` module plus thin per-coding modules, and a `discriminatedType` ADU switching frame-type/coding, which maps cleanly onto 3E/4E × binary/ASCII. The device-addressing **tag layer** I'd model on **s7** (`MemoryArea` + bit/word transfer-size + offset), since SLMP's device-code matrix (D/M/X/Y/W/B/R, per-device radix, bit/word) is structurally much closer to s7 than to modbus's flat register model. The later read optimizer would draw on s7's `S7Optimizer`/`S7BlockReadOptimizer`.

Before I open the first PR, two things I'd rather confirm up front:

1. **Placement** — does `protocols/slmp` (mspec) + `plc4j/drivers/slmp` work, or would you rather it incubate elsewhere first?
2. **Granularity** — is a staged, read-only-first PoC PR an acceptable way to start, or would you rather see a larger initial scope?

Happy to open a draft PR with the v0 scaffold + tests if that's easier to discuss concretely.

Start by comparing the existing modbus and s7 drivers, especially their mspec/SPI structure, then use the MELSEC Communication Protocol Reference Manual (SH-080008) to verify 3E binary batch-read details. The proposed entry points are protocols/slmp and plc4j/drivers/slmp; done means a read-only D-device v0 plus ParserSerializer tests for INT/WORD/DINT/REAL single requests, without hardware.

Written by the indexing model from the issue text.