feat(data): give Plutus data its own encoder

[solidsnakedev]

Data.toCBORBytes built a generic CBOR tree and let the CBOR encoder apply one set of options to all of it. Three rules of the node's Plutus data encoder (encodeData) never applied:

• A constructor index above 127 wrote its tag 102 [index, fields] pair with the list options; the node writes it as a definite two-item array.
• The SDK wrote -2^64 as a negative bignum; the node writes every integer from -2^64 to 2^64 - 1 with major types 0 and 1.
• The SDK wrote a bignum over 64 bytes as one byte string; the node chunks it at 64 bytes, like any byte string.

Data now writes a Data value straight to bytes with these rules under every preset, and lists, maps and constructor fields keep following the codec options. Every other value keeps its bytes under every preset. Data.toCBORBytes, Data.toCBORHex, Data.toDatumHash, the encode side of the Data schemas, redeemers, witness datums, inline datums, UPLC data constants and toScriptDataHash all use it. For a typical datum it runs several hundred times faster than the tree path. Decoding stays as it was, and decoded transactions keep using the tree path, which still needs CBOR.BoundedBytes.

Under CML_DATA_DEFAULT_OPTIONS the old tag 102 bytes followed the preset's reference library, which also writes the pair indefinite; the node does not, so the pair now follows the node under every preset.

The CBOR encoder now also writes -2^64 as 3bffffffffffffffff, and an integer decoded from a bignum tag keeps that tag when a decoded transaction is written back. A fresh, a decoded and a signed witness set therefore agree on -2^64, and decoded small bignums such as c24101 no longer turn into plain integers.

Closes #614
Closes #601
Closes #530