Add comments to clarify the order of struct parsing

The 'wire format' of the Transceiver messages encodes/decodes the fields
of the struct in reverse order to how they are declared in the Solidity
and Rust structs.
This is done safely, and we have unit tests to verify that the
encoding/decoding process is consistent on both sides. However, it's not
clear that this is intentional when reading through the code.
This comment should help with readability and hopefully will stop
reviewers from falling down rabbit holes.

Author: johnsaigle

evm/src/libraries/TransceiverStructs.sol

@@ -127,6 +127,8 @@ library TransceiverStructs {
             revert IncorrectPrefix(prefix);
         }
 
+        // The `amount` and `decimals` fields are parsed in reverse order compared to how they are declared in the
+        // `TrimmedAMount` struct. This is consistent with the Rust NTT implementation.
         uint8 numDecimals;
         (numDecimals, offset) = encoded.asUint8Unchecked(offset);
         uint64 amount;

solana/modules/ntt-messages/src/trimmed_amount.rs

@@ -96,6 +96,8 @@ impl Readable for TrimmedAmount {
         Self: Sized,
         R: io::Read,
     {
+        // The fields of this struct are intentionally read in reverse order. This is consistent
+        // with the equivalent code in the EVM implementation of NTT serialization.
         let decimals = Readable::read(reader)?;
         let amount = Readable::read(reader)?;
         Ok(Self { amount, decimals })
@@ -108,6 +110,8 @@ impl Writeable for TrimmedAmount {
         W: io::Write,
     {
         let TrimmedAmount { amount, decimals } = self;
+        // The fields of this struct are intentionally written in reverse order. This is consistent
+        // with the equivalent code in the EVM implementation of NTT serialization.
         decimals.write(writer)?;
         amount.write(writer)?;