Validate fixed PDU lengths and encoded item length overflow

[atlex00]

read_pdu did not enforce the required PDU-length value of 4 for A-ASSOCIATE-RJ, A-RELEASE-RQ, A-RELEASE-RP, and A-ABORT PDUs. Declared lengths below 4 already failed field-length validation, but lengths above 4 could be accepted: the decoder parsed the defined four bytes and discarded the additional bytes included in the declared PDU body. The chunk writers also converted encoded payload lengths with truncating as u16/as u32 casts, so payloads exceeding the corresponding length field could produce a truncated length value while the complete payload was written.

DICOM PS3.8 specifies a PDU-length of 00000004H for these PDUs (§9.3.4, §9.3.6, §9.3.7, §9.3.8) and defines variable PDU and item lengths as the number of bytes in their following content. This change rejects any other declared length for those fixed PDUs, replaces the length casts with checked conversions that report overflow, and adds the corresponding read and write error variants.

[Enet4]

Thank you for your pull request. Can you look into the two concerns inline?

[Enet4]

This option could be shortened a bit. How about this?

Suggested change

	#[arg(long)]
	reject_trailing_fixed_pdu_bytes: bool,
	#[arg(long = "no-trailing-fixed-pdu-bytes")]
	reject_trailing_fixed_pdu_bytes: bool,

[Enet4]

I understand that this fixes a false positive in which a client would erroneously claim to be communicating with a TLS server? We can incorporate that, but this either needs to be documented differently in the PR, or split into a separate one.