parallel-workload: Use more interesting expressions in SELECT, views and conditions; support COPY FROM STDIN; prepared statements; run 10x faster

[def-]

Motivated by https://materializeinc.slack.com/archives/CU7ELJ6E9/p1756852503595199

I always knew we'd need more general expressions, so finally got around to implementing them (and removing all the TODO comments).

That reproduces the original issue easily in 4/9 runs: https://buildkite.com/materialize/nightly/builds/13133

+++ [worker_8] Query failed: INSERT INTO "db-pw-1757078559-0"."s-0"."t-1" ("c-0-bigint", "c-1-mz_timestamp") VALUES (-1154873474221047172, MZ_TIMESTAMP '19317-9-27'), (-9223372036854775808, MZ_TIMESTAMP '66822-9-13'), (9223372036854775807, MZ_TIMESTAMP '17235-10-21'), (-4665962949847538769, MZ_TIMESTAMP '69332-6-15'), (8444606562024686967, MZ_TIMESTAMP '71526-12-6'), (6100859744477175015, MZ_TIMESTAMP '96494-10-12'), (-9223372036854775808, MZ_TIMESTAMP '59117-4-1'), (119013262017748147, MZ_TIMESTAMP '78394-6-22'), (-6428999613294955046, MZ_TIMESTAMP '69507-9-2'), (214639980754110942, MZ_TIMESTAMP '70046-11-5'), (-9223372036854775808, MZ_TIMESTAMP '93346-6-14') RETURNING 94, abs(-22.491346699927163), abs(6921), current_timestamp(), TIME '6:7:10.991542', '{-93}'::int[], -36.12842768411257, '{"key0": "-33", "key1": "-71", "key2": "84", "key3": "-43", "key4": "-1", "key5": "85", "key6": "8", "key7": "13", "key8": "68", "key9": "6"}'::jsonb, cast((DATE '58327-7-20') as text), 1523333707; HTTP XX000: internal error: cannot evaluate unmaterializable function: CurrentTimestamp

This also found an unrelated bug: https://github.com/MaterializeInc/database-issues/issues/9656

New run with #33500 included should show us if it's fixed: https://buildkite.com/materialize/nightly/builds/13136

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.

[def-]

This is far from exhaustive btw, but the same is true of everything in parallel-workload.

[def-]

Update: https://github.com/MaterializeInc/database-issues/issues/7578 is more likely now, but https://github.com/MaterializeInc/database-issues/issues/9656 is currently blocking merging this PR because it's panicking a lot in CI. Edit: I'll disable the persist audit in parallel-workload.
Edit2: That doesn't help much, getting wrong results then:

('WS XX000: Invalid data in source, saw retractions (1) for row that does not exist: [Interval(Interval { months: -126842016, days: 61, micros: 292763369000000 }), Interval(Interval { months: -61826196, days: 231, micros: 263472992000000 }), UInt16(9253), UInt64(1358179014714732766)]\n    ', 'DELETE FROM "db-pw-1757091288-0"."s-0"."t-1" WHERE ((TIME \'9:26:33.924435\') + ("db-pw-1757091288-0"."s-0"."t-1"."c-0-interval")) >= (TIME \'16:13:32.190114\');')