Reject building a user monoid from a built-in BinaryOp - #617

Registering a monoid from a built-in binaryop used to crash partway
through construction:

Monoid.register_new("mymax", binary.max, 0)
    AttributeError: 'TypedBuiltinBinaryOp' object has no attribute
    '_monoid' and no __dict__ for setting new attributes

and by the time it raised, it had already repointed binary.max's monoid
association at the half-built monoid, so binary.max.monoid stayed
corrupted for the rest of the session. (This is the latent bug that the
fmax/fmin identity test surfaced on mapnumpy=True CI runs.)

Even patched over, the result would lie. SuiteSparse ignores the
identity passed to GrB_Monoid_new whenever the built-in op already has a
built-in monoid, measured with GxB_Monoid_identity:

Monoid.register_new("mymax", binary.max, 0)[INT64] -> -9223372036854775808
the same monoid built on a UDF max                 -> 0

The override applies to exactly the ops that have built-in monoids (max,
min, plus, times, any) and not the rest (minus, first, second, pow,
bor, lxor), so a permissive fix would produce a monoid whose Python-side
identity silently disagrees with what GraphBLAS computes with. If a
monoid over a built-in op's function made sense, the built-in monoid
would already exist.

Monoid._build now rejects built-in binaryops up front with a TypeError
that points at BinaryOp.register_new / register_anonymous as the way to
build a monoid over the same function with a chosen identity. Built-ins
are detected as ops with neither a Python function nor a numba function,
which also covers assembled ops like binary.numpy.float_power. The
rejection happens before any object is created, so nothing is mutated on
the failing path.