Use standard Plutus Data JSON encoding for builtin_data values in cape-tests.json

[nau]

Problem

The cape-tests.json files use a custom compact notation for builtin_data values:

{
  "deposited_escrow_datum": {
    "type": "builtin_data",
    "value": "0(0() 1000)"
  }
}

This notation (0(fields...) for constructors, #hex for bytestrings, [a b] for lists, {k:v} for maps, plain integers) is not a standard format and is not formally specified anywhere in the CAPE documentation. Every compiler submission must implement a bespoke parser for it, which is unnecessary friction.

Suggestion

Replace the custom notation with one of the two existing standard Plutus Data representations that every Cardano toolchain already supports:

Option A: Plutus JSON schema (used by cardano-cli, Aiken, Plu-ts, etc.)

{
  "deposited_escrow_datum": {
    "type": "builtin_data",
    "value": {"constructor": 0, "fields": [{"constructor": 0, "fields": []}, {"int": 1000}]}
  }
}

This is the ScriptDataJsonDetailedSchema from cardano-cli. It is widely adopted and well-documented in the Cardano CLI docs.

Option B: UPLC text Data syntax (from the Plutus spec)

{
  "deposited_escrow_datum": {
    "type": "builtin_data",
    "value": "Constr 0 [Constr 0 [], I 1000]"
  }
}

This is the Data syntax used inside (con data ...) in UPLC text format. Every UPLC parser already handles it.

Benefits

• Every Cardano toolchain already has a parser for at least one of these formats
• No custom parser needed per submission -- reduces onboarding effort for new compilers
• The format is formally specified (Plutus spec for Option B, CIP-related for Option A)
• Less room for ambiguity (e.g., is whitespace significant in the current format? How are nested maps handled?)

Notes

The current format works fine and is reasonably readable. This is a quality-of-life suggestion to lower the barrier for new compiler submissions, not a blocking issue.