Make config attribute assignment raise instead of silently no-op - #608

Measured before this change: `graphblas.config.autocompute = False`
left `config["autocompute"]` at True and added a dead `autocompute`
entry to `vars(config)`. donfig.Config defines no __setattr__ for
options, so the write landed on the instance and the real option never
moved. The mistake is easy to make and leaves no trace.

graphblas.config is now an instance of a donfig.Config subclass whose
__setattr__ rejects writes that are not donfig's own. For a known option
the AttributeError names the canonical idioms (config.set(name=value),
optionally as a `with` block, and config[name] to read). For an unknown
name it says so and lists the known options, deliberately WITHOUT
advising config.set(): donfig's set() accepts arbitrary keys, so pointing
there would trade a loud error for a silently-created bogus option, the
same class of trap this change exists to close.

The allowlist of writable attributes is derived rather than hardcoded:
the subclass snapshots vars(self) once donfig's __init__ returns, so a
donfig release that adds or renames an internal field cannot break
attribute access here. Today that snapshot is name, env_prefix, env,
main_path, paths, defaults, deprecations, config, and config_lock. An
instance built without running __init__ has no allowlist yet and stays
permissive, so the guard cannot raise from a half-built object.

What this does not change: reading options, config.set() as a call or
as a context manager, config[name], get(), update(), refresh(),
to_dict(), and writes to donfig's own attributes all behave as before.
Item assignment (config[name] = value) was never supported by donfig
and still raises TypeError.

Under the pinned config (--backend suitesparse --blocking
--no-mapnumpy), the suite goes from 1073 to 1075 passed by the two tests added here;
141 skipped is unchanged.