Reject UDT UDF returns that cannot fill the element - #590

A UDF over an array UDT whose return does not fit the element is not a type
error. Numba's `Array` type carries `ndim` but not its extents, so returning
`x[:2]` from a 9-element UDT types identically to returning `x`. The
wrapper's `z[:] = ...` then raises inside the cfunc, where Numba prints the
traceback and returns. GraphBLAS is handed no error, and the element keeps
whatever was already in the buffer, so the caller gets a wrong answer and no
exception. A record UDF that under-fills an array-typed leaf fails the same
way and abandons the write part-way: every leaf after the short one, scalar
leaves included, keeps what SuiteSparse had there.

Extents can only be recovered by running the function, so `_get_udt_wrapper`
and the IndexBinaryOp wrapper now call it once on stand-in operands and check
that the result fits the UDT. Fitting is not the same as matching. Slice-assign
broadcasts, so a `(1,)` return fills a `(6,)` element and a `(1, 3)` return
fills both rows of a `(2, 3)` one; both work today and must keep working, and
an equality check would reject them. `_fits_by_broadcast` applies numpy's
assignment rule instead, and `test_udt_broadcast_matches_numba_slice_assign`
pins it against Numba's own slice-assign in both directions, including the two
ranks where broadcasting alone gives the wrong answer. The operands are ones
rather than zeros for the same reason `dtypes._sample_values` avoids zeros: a
UDF that divides by an operand would raise on a zero-filled probe, and a
raising probe is treated as "cannot check" rather than as a failure.

The check is best-effort, and this commit should not claim more. A UDF that
raises on the probe values is not checked at all, so one that also returns a
shape that does not fit still reaches the wrapper and still fails silently,
exactly as it did before. The wrapper's slice-assign remains the only backstop
that always runs. What the check buys is that the common case, a UDF that is
simply wrong about the shape, becomes an error at registration instead of a
wrong answer at apply time.

Because the probe reports the shape for the values it was run on, the
diagnostic says so. A UDF whose output shape depends on its operands' values
rather than their types can otherwise be rejected on a shape it would never
return for real data.

This is a judgement call rather than a straight fix, and it is cheap to
decline. Typing an op for a UDT now executes the user's function, where before
it only compiled it. `OpBase.__contains__` is implemented as a typed lookup, so
`udt in some_op` runs user code as a side effect of a membership test.
Measured: registering an op runs no probe, since compilation stays lazy, but a
single `udt in some_op` runs exactly one. That probe costs no extra compile,
because it calls the function with an `ndarray` and the wrapper's
`numba.carray` view needs that same specialization anyway. A/B with the check
stubbed out: 93.4 ms median disabled against 92.1 ms enabled, two Numba
specializations either way.

Only array UDTs and records that actually have an array leaf are probed, so an
ordinary record UDF is still typed without running user code.

The array-UDT paragraph in `docs/user_guide/udt.rst`, added one commit earlier,
described the rule as building "a new array of the same shape". It now states
the rule the check enforces, and says the shape is learned by running the UDF.

If this is declined, the array-UDT view change it sits on still stands. A
return that does not fit stays memory-safe, because the slice-assign cannot
overrun the element, and goes back to being silent.