Fix gh-559 memory growth: build .ss lazily instead of storing it - #598

Every Matrix and Vector was born inside two reference cycles: the stored
self.ss held _parent back to the object, and so did ss.config.  Instances
therefore died by the cyclic garbage collector rather than by refcount, and
their C-side GrB buffers accumulated between gc sweeps.  With gc disabled, a
scaled version of the gh-559 batched-mxm loop grew without bound.  The .ss
namespace is now built per access (a property inside the existing
class_property), nothing is stored on the parent, no cycle forms, and objects
free as soon as their refcount drops.

Two user-visible behavior changes:

  A.ss is A.ss is now False.  It was True, because .ss was a stored attribute;
  each access now returns a fresh namespace object.  Code that compares .ss by
  identity, or that caches attributes on it, will see the difference.

  Assigning A.ss now raises AttributeError.  It previously succeeded and
  silently replaced the namespace, because "ss" was in __slots__.

Class-level Matrix.ss and Vector.ss still resolve to the ss class, so the
import_* classmethods are unchanged.

Building the namespace per access costs roughly 215ns against roughly 78ns for
the stored attribute (timeit), so about 1% of a single small mxm plus to_dense
iteration, which runs about 15us.  The .ss namespace is typically touched once
per user operation.

Six of the eight new tests fail without the fix.  They assert on the reference
graph rather than on process memory, which a functional suite cannot see and
which an RSS delta would measure only statistically: a weakref must be dead the
instant the last strong reference drops with the cyclic collector switched off,
and a batched mxm loop must not raise the number of live Matrix objects
reported by gc.get_objects().  The remaining two cover invariants the fix has
to preserve, class-level access and views whose _parent is set, so they pass
either way.