Translate Clamp on Int32Range, Int64Range and DecimalRange #406

Problem

Clamp(value) on a range runs in memory only (docs/efcore.md#what-runs-where). The obstacle the docs gave until #402 ("a CASE per shape") is overstated: GREATEST and LEAST skip NULL, so an unbounded side needs no branch.

Change

Translate Clamp on Int32Range, Int64Range and DecimalRange, matching RangeExtensions.Clamp:

• Memory's rule: null for the empty range; the value itself inside; otherwise the finite bound it falls outside of, whatever that bound's inclusiveness (on a continuous type an exclusive bound is returned although the range doesn't contain it). An unbounded side never constrains. The value is first passed through NormalizeElement.
• SQL: CASE WHEN isempty(x) THEN NULL ELSE LEAST(GREATEST(v, lower(x)), <upper>) END. <upper> is upper(x) for numrange. For int4range/int8range it is upper(x) - 1, because PostgreSQL canonicalizes to an exclusive upper bound where memory's End is inclusive. upper(x) - 1 can't overflow, since the canonical exclusive bound is at least one above a real value.
• Measured on PostgreSQL 16: LEAST(GREATEST(15, lower('(,10]')), upper('(,10]') - 1) is 10.
• To check first: DecimalRange's NormalizeElement (scale) against what numeric returns, since Same compares the loaded decimal.
• Declared nullability: NULL for a NULL range or a NULL value (rule (c)).

Done when

Every condition on the 10.3.0 epic's parity list holds for the three types, against memory over the loaded rows on a live server. translation-support.json classifies them server (the other range types stay client with their reason), and the docs list the three under "Runs as SQL". main first, then the cherry-pick.