[expr] Add a proptest for the is_monotone annotations

[bkirwi]

Motivation

Why think of counterexamples when the computer can do it?

(We could also add more functions to the abstract interpreter tests, which cover this codepath... but we can test this directly more cheaply for more functions, and this keeps any test failures closer to the problematic code.)

Tips for reviewer

Inspired by: #29514

This sadly produces a counterexample for left when passed a negative argument... 'a' < 'aa' < 'z' but left(_, -1) returns '' < 'a' > ''. Concat seems fine in the second arg however!

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.

[ggevay]

This is great, thank you! Monotonicity can be indeed really tricky sometimes!

I think we could merge this as it is, and then make it more comprehensive later when we have time:

• Could make this a part of test_smoketest_all_builtins.
• Could use arb_datum_for_column in addition to interesting_datums.
• Could make it test could_error, preserves_uniqueness, inverse.

I've created a follow-up issue: https://github.com/MaterializeInc/materialize/issues/29584

[ggevay]

I've adjusted #29514 and brought it out of draft.

[bkirwi]

I've created a follow-up issue [...]

Great! Definitely support integrating into whatever feels most natural for you. Thanks for the review!