Fix: zero-valued BigInt tx fields encode as non-canonical RLP (0x00)

[KabaDH]

Fix: zero-valued BigInt tx fields encode as non-canonical RLP (0x00)

Summary

ETHTransactionUtils.bigintToBytes() encoded a zero BigInt as a single
0x00 byte instead of an empty byte string. RLP requires the canonical empty
form for integers, so nodes reject these transactions:

rlp: non-canonical integer (leading zero bytes), decoding into
(types.DynamicFeeTx).GasTipCap

The regression came in with the v8.0.0 bump of blockchain_utils to ^6.0.0:
bitlengthInBytes(0) changed from 0 to 1, so toBytes(0) now yields [0]
instead of []. It broke L2 transfers like Arbitrum, where
maxPriorityFeePerGas (GasTipCap) is normally 0; mainnet was unaffected
only because the tip there is effectively always > 0.

The fix guards the zero case in bigintToBytes, mirroring the guard already
present in the sibling intToBytes, so encoding is correct independent of the
dependency's internals.

Change

   static List<int> bigintToBytes(BigInt value) {
+    if (value == BigInt.zero) return [];
     final toBytes = BigintUtils.toBytes(
       value,
       length: BigintUtils.bitlengthInBytes(value),
     );

Impact

• One centralized helper fixes every zero-able BigInt field across all tx
  types (legacy / 1559 / 2930 / 4844 / 7702 / 712) — including the commonly-zero
  EIP-7702 authorization nonce.
• Non-zero encoding is bit-identical; decode round-trip is unaffected ([] and
  [0] both map back to 0).

Testing

Added tests in test/etherum/transaction_test.dart covering the helper and the
real Arbitrum zero-tip EIP-1559 case. They fail pre-fix, pass post-fix; the
test/etherum/ suite is green.

[KabaDH]

Hi, @mrtnetwork ! When you have a chance, could you please take a look at #33 and #34 ?
I'd really appreciate your review. Thanks for your time!