Broaden types converted to jsonb numeric

[frankmcsherry]

We detect a few scalar types that can convert into jsonb's numeric representation, but types we don't explicitly match are converted to strings.

Todo:

1. add tests that cover these cases. The user reported error was for select jsonb_build_object('data', count(*)) from ...
2. add exhaustive matches, to avoid missing cases like this in the future.

Putting up without this work to raise for discussion. Specifically, the code comments say

///   * All numeric types are converted to `Float64`s, then become JSON numbers.

which .. isn't actually what happens (they are directly converted to Numeric { max_scale: None }). If it is important that something very close to that happens we should discuss, but we already convert Numeric, which subsumes all of our integer types, into Numeric rather than Float64 or anything similar.

Motivation

Tips for reviewer

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[antiguru]

Looks good. We might have some work to do in this area. For select jsonb_build_object('data', 10000000000000000000000000000000000);, Postgres and Materialize disagree:

postgres=# select jsonb_build_object('data', 10000000000000000::int8);
     jsonb_build_object
-----------------------------
 {"data": 10000000000000000}
(1 row)

Materialize:

jsonb_build_object
{"data":1e+34}

[frankmcsherry]

Merging, but to ack the comment: I don't think the PR regresses here does it? I'm imagining that number is in numeric territory, and that code went unchanged.