Remove the copying collector in favor of simple mark/sweep

The marginal performance gains weren't worth the
memory and complexity costs.

Although I think we could close the performance gap (Lazy Sweep),
agressively optimizing this collector is a dead-end.
This should be a simple and fairly lightweight collector.
An insanely allocation-intensive workload like `binary_trees`,
wouldn't realisticly depend on "zerogc-simple" for collection.
They would either manually allocate from a typed-arena,
or use a optimized generational garbage collector (planned for DuckLogic).

We should avoid bloating the complexity of the "simple" collector
for these sort of insane benchmarks.

The arenas for small objects is a reasonable optimization.
It actually *reduces* memory usage in many cases (like binary trees).
Small objects are common with managed languages.
I figure Rust code would generally use this for selected types in a
complex objects graph, where nodes are fairly small and of consistent types.

On the other hand, we should switch to an explicit stack of grey objects.
Using recursion could risk stack overflow (See 9a9634d68a4933d00).
Although stack overflow is technically "safe", we should definitely
default to avoid it. Tracing a long linked list shouldn't blow up
the collector by default.....
If the user wants the optimization, they can explicitly ask for it.
It's simple to implement and results in signficant gains: 9a9634d

Although I think I'll personally use the simple collector for short tasks,
we should definitely look into returning memory to the OS (somehow).
To be clear this is only a problem when small-object arenas are enabled.

This implicitly closes #4 by deleting the duplicate code

Cargo.toml

@@ -20,4 +20,4 @@ arrayvec = { version = "^0.4.6", optional = true }
 ndarray = { version = "^0.10.12", optional = true }
 
 [workspace]
-members = ["libs/simple", "libs/copying"]
+members = ["libs/simple"]