Support bigint

[SebastienGllmt]

The CDDL specification mentions bigint in the following section

      biguint = #6.2(bstr)
      bignint = #6.3(bstr)
      bigint = biguint / bignint
      integer = int / bigint
      unsigned = uint / biguint

However, historically we don't support any kind of bigint and instead just use big_int = _CDDL_CODEGEN_EXTERN_TYPE_

This isn't great because every Plutus datum needs bigint, so anybody that wants to use cddl-codegen to generate code for their dApp (ex: projected NFT dApp) needs to tackle this

In my opinion, we have two options:

1. Mention somewhere in the docs that if you need bigint and is for Cardano to just import relevant CML crate and use BigInt from it
2. Add bigint as part of the static types shipped in cddl-codegen. This means code duplication if you're using multiple cddl-codegen generated libraries, but this is the same as having duplicate definitions of DeserializeError which we already do

[rooooooooob]

It should be worth noting that big_int (defined in conway.cddl), while very similar, is NOT the same as the bigint defined in the CDDL/CBOR RFC spec.

big_int = int / big_uint / big_nint
big_uint = #6.2(bounded_bytes)
big_nint = #6.3(bounded_bytes)

bounded_bytes = bytes .size (0..64)
  ; the real bounded_bytes does not have this limit. it instead has a different
  ; limit which cannot be expressed in CDDL.
  ; The limit is as follows:
  ;  - bytes with a definite-length encoding are limited to size 0..64
  ;  - for bytes with an indefinite-length CBOR encoding, each chunk is
  ;    limited to size 0..64
  ;  ( reminder: in CBOR, the indefinite-length encoding of bytestrings
  ;    consists of a token #2.31 followed by a sequence of definite-length
  ;    encoded bytestrings and a stop code )

So it has the same general structure and might USUALLY be equivalent, but the bytes are encoded in a special way, I assume to get around copyright issues when storing bytes on-chain without the cumbersome 64 byte limit that we had with transaction metadata.

If we export anything we should be consistent with Int ideally. Right now Int is always output whenever it is used, we could do the same with bigint. This Bigint would need to be slightly different from CML's BigInt due to that encoding detail.

but this is the same as having duplicate definitions of DeserializeError which we already do

You can avoid this now by passing in --common-import-override=cml-core (or wherever DeserializeError, serializaton module, etc are)

On another note, if creating cddl-codegen libs to work with plutus datums is going to be a common thing we could provide docs + a tool similar to what we do for transaction metadatums. We could even go a step further and allow that tool to now only validate the cddl to see if it conforms like the existing one in tools/metadata-cddl-checker but to also have it call cddl-codegen with the appropriate parameters and maybe even generate some basic conversion functions like we have in cip25/cip36 to go to/from the custom type to PlutusDatum (or TransactionMetadatum/Metadata if we update the tx one too).