Reject record UDT pairs whose leaf counts differ - #591

`_check_udt_pair` rejects two record operands that disagree on shape, but it
compared only top-level field names. Two records can share those and still
nest differently: `[("a", f8), ("b", f8)]` against
`[("a", [("n1", f8), ("n2", f8)]), ("b", f8)]` both report fields
`["a", "b"]` while contributing two leaves and three. The codegen walks one
operand's leaf paths and applies them to both, so applying the scalar path
`["a"]` to the nested side asks Numba to add a float to a record.

Measured before this change, that pair gets through the checks and comes
back from Numba's typing pass as:

    UdfParseError: binary.plus does not work with (_NestFlat, _NestDeep):
    No implementation of function Function(<built-in function add>) found
    for signature: >>> add(float64, Record(nst_n1[type=float64;offset=0],
    nst_n2[type=float64;offset=8];16;False))

That reports a compile failure for what is the same shape disagreement the
three sibling checks in the same function already report as a KeyError.
Comparing leaf counts makes it the fourth of those checks.

The exception class changes, and that is visible in both directions:
UdfParseError derives from GraphblasException, not from KeyError, so code
catching KeyError to mean "no such op" now catches this pair, and code
catching UdfParseError no longer does. `OpBase.__contains__` catches both,
so `udt in binary.plus` is unaffected either way.