Extend the monoid guard to built-ins that carry a UDT fallback func - #619

…/max

Behavior fix. monoid.min and monoid.max generate a UDT's identity field
by field, and _scalar_identity picked the integer arm with
np.issubdtype(dtype, np.integer). numpy files timedelta64 under
np.integer, so a record with a timedelta64 field reached np.iinfo, which
rejects it:

    rec = dtypes.register_anonymous(np.dtype([("n", np.int64), ("t", "m8[s]")]))
    monoid.min[rec]       # before: ValueError: Invalid integer data type 'm'.
    rec in agg.min        # before: the same ValueError, not False

A datetime64 field already got "KeyError: monoid.min does not work with
...: field 't' has unsupported dtype datetime64[s]", and `in` answered
False. Test the dtype's kind instead, so a timedelta64 field takes that
path too:

    monoid.min[rec]       # after: KeyError ... field 't' has unsupported dtype timedelta64[s]
    rec in agg.min        # after: False

Real identities for timedelta64 fields (its own max and min, with NaT
in mind) are a separate enhancement.

Behavior fix. Monoid._compile_udt handed a binary op whose return type
differs from its input type straight to GrB_Monoid_new_UDT, which
rejects it with a DomainMismatch that has no message, also from `in`:

    op = BinaryOp.register_anonymous(lambda x, y: x["a"] + y["a"], is_udt=True)
    m = Monoid.register_anonymous(op, 0)
    m[rec]       # before: DomainMismatch (empty message)
    rec in m     # before: the same DomainMismatch

Check the compiled op's return type first and raise a TypeError, the
error the neighbouring check (two different input types) raises:

    m[rec]       # after: TypeError: monoid.<lambda> does not work with rec: a
                 #   monoid's binary operator must return its input type, rec, not INT64
    rec in m     # after: False

Behavior fix. The lazy branch stored register_new's arguments for the
delayed call but left is_idempotent out, so the monoid built on first
access was never idempotent:

    Monoid.register_new("m", op, 0, is_idempotent=True, lazy=True)
    monoid.m.is_idempotent    # before: False
                              # after: True

The eager branch already passed it.

The test registers lazy_idem in the binary and monoid namespaces, so
test_operator_types ignores it like the other names test_lazy_op makes.

Behavior fix. Monoid._compile_udt generated a field-wise identity
whenever the monoid had no identity and its name was plus, times, min or
max. A user monoid gets its name from its BinaryOp, which gets it from
the function, so a user op called `min` (or a monoid given name="plus")
silently took the built-in's identity and gave wrong results. With an op
that takes the field-wise max and identity None:

    op = BinaryOp.register_anonymous(fieldwise_max, "min", is_udt=True)
    v = [(1, 2), (5, -3)];  w = [(-1, -2), (-5, -3)]
    Monoid.register_anonymous(op, None)          # name "min"
        before: identity (INT64_MAX, INT64_MAX); v.reduce -> (INT64_MAX, INT64_MAX)
    Monoid.register_anonymous(op, None, "plus")
        before: identity (0, 0); v.reduce -> (5, 2), w.reduce -> (0, 0)
    both, after: KeyError: monoid.<name> does not work with ...: no identity value

Generate the identity only for a built-in monoid, the ones with no
_binaryop of their own. A user monoid with an identity is unaffected.

test_udt_monoid_op_must_return_its_input_type matched the error against
"_BuiltinOpsRec", the name the record_udt fixture registers. But
register_anonymous returns the one DataType for an np.dtype and gives it
the newest name, and test_udt_op_pickle registers the same record dtype
as "_PickleUdt". In random order, with a record_udt test, then
test_udt_op_pickle, then this test, the message said "_PickleUdt" and
the match failed (wave 2 CI: 13 jobs, e.g. 122634118659 and
122634118406, on both backends and with mapnumpy on or off). Match the
fixture's name as it is when the error is raised.