feat(api): add API for unwrapping JSON values into backend-native values

[cpcloud]

Adds str, int, float, and bool properties to JSONValue as well as an unwrap_as method for easier programmatic usage and more fine-grained casting.

Unless someone really hates the static property names, I'd prefer to keep them as they are. Open to alternative names for unwrap_as though.

In theory this can all be done with casting, but if you look at what's being done in the various backends it's typically a lot more involved than that. Trino in particular requires queries over JSON to be VARCHAR inputs, when then have to be cast back to its JSON type to be able to cast that to the desired output type.

Complicating the cast branching just for the JSON -> not JSON case seemed like the wrong tradeoff.

I went with these names to match the map and array APIs, and to match the short type names we have for the specific types (str, int, float, and bool), which exist to match the equivalent Python types.

[cpcloud]

@dixdotdev I've added your example into the docstring for the JSONValue.str API.

Would you mind taking this PR a spin?

[dixdotdev]

Yep happy to try this out tomorrow. I've reviewed the code from mobile and it seems like a pretty elegant solution, but proof is in the execution!

[dixdotdev]

So I've taken a spin through it, and while it does work as intended I think that as a replacement for .cast(type) it deviates a bit syntactically, particularly when plucking out datatypes from iterators or objects.

I think ideally the solution should allow for a similar syntactic expression so your original naming with .unwrap(type), or .unwrap_as(type) might make more sense when considering other functional uses.

[dixdotdev]

I've tried it out for my implementations and it seems to work as expected with the .unwrap_as() as we discussed- just a couple of queries in the docstrings for clarity.

[gforsyth]

new unwrap tests are passing on clouds:

🐚 pytest -m "bigquery or snowflake" ibis/backends/tests/test_json.py -k "unwrap"
================================ test session starts ================================
platform linux -- Python 3.12.2, pytest-8.1.1, pluggy-1.4.0
Using --randomly-seed=2966770701
benchmark: 4.0.0 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000)
rootdir: /home/gil/github.com/ibis-project/ibis
configfile: pyproject.toml
plugins: xdist-3.5.0, hypothesis-6.100.1, snapshot-0.9.0, randomly-3.15.0, mock-3.14.0, benchmark-4.0.0, cov-5.0.0, repeat-0.9.3, clarity-1.0.1, pytest_httpserver-1.0.10
collected 240 items / 224 deselected / 16 selected                                  

ibis/backends/tests/test_json.py ................                             [100%]

=================== 16 passed, 224 deselected in 80.76s (0:01:20) ===================

[gforsyth]

This looks good to me! I suppose this will show Risingwave as supporting these ops in the support matrix, but we can add explicit NotImplementeds in a followup.