Refactor CLARIOstarBackend command handling and add plate geometry

[maraxen]

Changed a bit of how the command is handling with what we have learned and integrated plate geometries.

I have tested read_absorbance and validated it sends the commands succesfully and plate reading happens, but it seems to have trouble catching the response, but I wanted to start the PR to get feedback on the other aspects while I debug that and the luminesence.

[maraxen]

This PR refactors how commands are processed by the send function and introduces dynamic handling of plate dimensions and well positioning.

Command Processing Changes

When commands are processed by send, the following occurs:

• Length Calculation: The total message length is calculated as: len(byte_array) + 7 (4 bytes for the header, 3 bytes for checksum/end bytes).
• Header Parsing: This length is parsed and formatted into the 4-byte header.
• Checksum Generation: The command bytes are processed to generate the checksum.

Plate Encodings & Future Improvement

The logging for plate encodings now includes a human-readable explanation for each byte in the debug stream.

I think we should also consider using a dedicated data structure (dataclass + struct?) to model the plate encoding and command structure instead of raw byte manipulation. While not used in existing PLR code as far as I know, moving away from raw byte manipulation will be crucial as we pursue support of multiple modalities (wavelengths, plate modes, additional settings) and past endpoint measurements. A structured approach will provide a cleaner way to assess which bytes modulate specific instrument settings, making the system easier to debug and maintain without sacrificing ease of use for the user. This also makes following the logic of the code easier as a developer in my opinion.

Work Remaining

I need to figure out what is going wrong on receiving the data stream back from the plate reader. It would also be great to get @BioCam to try to use this on the Plus. I suspect that there are some firmware differences that emerge into different commands. I'm hoping the eeprom data can delineate variants well enough for us to parse, but this is another area where having a defined data structure might make things easier to develop compared to on the fly decision trees in the code.