Wrap contract id hash values in a nominal type

[leighmcculloch]

What

Wrap contract id hash values in a type naming the type of value contract id.

Why

So that XDR-JSON tooling can identify that these contract ID values are in fact contract IDs, that can be rendered as C addresses, instead of only rendered as hashes.

Today XDR-JSON renders contract IDs as so:

$ echo 'AAAAAQAAAAAAAAABexsk1mMWXsuq0OtITJJJN70r1EUt5P08WpdWJ3sBY7UAAAABAAAAAAAAAAIAAAAPAAAABG1vYXIAAAAEAAAAAAAAAAQAAAAA' \
    | stellar-xdr decode --type DiagnosticEvent

{
  "in_successful_contract_call": true,
  "event": {
    "ext": "v0",
    "contract_id": "7b1b24d663165ecbaad0eb484c924937bd2bd4452de4fd3c5a9756277b0163b5",
    "type_": "contract",
    "body": {
      "v0": {
        "topics": [{"symbol": "moar"},{"i32": 0}],
        "data": {"i32": 0}
      }
    }
  }
}

After this change, it can render them as:

$ echo 'AAAAAQAAAAAAAAABexsk1mMWXsuq0OtITJJJN70r1EUt5P08WpdWJ3sBY7UAAAABAAAAAAAAAAIAAAAPAAAABG1vYXIAAAAEAAAAAAAAAAQAAAAA' \
    | stellar-xdr decode --type DiagnosticEvent

{
  "in_successful_contract_call": true,
  "event": {
    "ext": "v0",
    "contract_id": "CB5RWJGWMMLF5S5K2DVUQTESJE332K6UIUW6J7J4LKLVMJ33AFR3LPBW",
    "type_": "contract",
    "body": {
      "v0": {
        "topics": [{"symbol": "moar"},{"i32": 0}],
        "data": {"i32": 0}
      }
    }
  }
}

This also follows the pattern of naming values like Account IDs, which are just wrapped PublicKeys.

This change is binary compatible, but like most XDR changes will create breaking changes in code generated SDKs.

This change is targeting curr because it looks like CAP-67 changes are targeting curr.

Follow on change to rs-stellar-xdr is here:

• Add ContractID typedef for improved XDR-JSON rs-stellar-xdr#427