Support 'hex-string' de-serialization method on getBytes operators

[guidiaz]

• 'hex-string' method is mostly used in Web3/EVM contexts.
• Optional second parameter would need to be added:
  • RadonMap.getBytes(key: string, method?: string)
  • RadonArray.getBytes(index: number, method?: string)
  • RadonString.asBytes(method?: string)

[aesedepece]

I'd absolutely love to have this.

I've always envisioned it as:

• RadonString.asBytes(encoding: RadonBytesEncoding) -> Result<RadonBytes>
• RadonMap.getBytes(key: string, encoding: RadonBytesEncoding) -> Result<RadonBytes>
• RadonArray.getBytes(index: number, encoding: RadonBytesEncoding) -> Result<RadonBytes>

#[derive(Deserialize, Debug, Default, Serialize)]
enum RadonBytesEncoding {
    #[default]
    Hex = 0,
    Base64 = 1,
}

[guidiaz]

As a natural approach to web3 interactions, these other operators would also be great to have:

• RadonBytes.asInteger() (big-endian assumed)
• RadonString.asInteger(encoding?: RadonBytesEncoding) -> Result<RadonInteger>

#[derive(Deserialize, Debug, Default, Serialize)]
enum RadonBytesEncoding {
    #[default]
    Hex = 0,
    Base64 = 1,
    Decimal = 2,
}

[aesedepece]

As a natural approach to web3 interactions, these other operators would also be great to have:

* `RadonBytes.asInteger()` (big-endian assumed)

* `RadonString.asInteger(encoding?: RadonBytesEncoding) -> Result<RadonInteger>`

Sure, that's a great addition!

I agree on the point of assuming Big-Endian. Otherwise we'd need to have separate entries in RadonBytesEncoding for the BE and LE versions of each encoding.

We'd better simply have a RadonBytes.flip operator that does the BE<>LE conversion.

[guidiaz]

ArrayGetBytes and MapGetBytes would be unneccesary for two reasons:

• We cannot expect for a RadonMap item to contain binary values after a parseJSONMap() or parseJSONArray() is processed.
• In practice, they'd get solved by the succession of ArrayGetString/MapGetString and StringAsBytes.