Seperate GC into multiple implementations

[Techcable]

After refactoring out common code, I want to separate the different modes of zerogc-simple into their own crates.

Right now, we have two combinations of modes:

1. Threading: Either thread-safe or thread-unsafe
2. Count: Singleton or multiple collectors

Feature flags control these modes.

We've already finished separating the (very complex) context code into its own zerogc-context crate, so we've already made great progress! (See commit 44b3463)

I am planning to re-use much of this code when I implement generational GC (#14).

TODO

• Seperate into zerogc-context
• Special allocator crate
  • Basic interface
  • Delegating malloc implementation (using std::alloc)
  • Port the small-object-arenas code to the new API
    • TODO: Cleanup interface
  • Support controlling specific segments, chunks, and objects
  • Support compacting/copying collectors??
• Finally split zerogc-simple into multiple implementations
  • Thread safe, global singleton implementation
  • Thread-unsafe, multiple collectors
    • This is essentially a garbage collected arena
    • Should the zerogc-arena collector be separate from zerogc-simple???
  • Thread-safe, multiple collectors (
  • I'm pretty sure I'm going to drop singleton/thread-unsafe

Open Questions

1. Should we separate tracing code into a zerogc-mark or have it somewhat duplicated among implementations
   • I think zerogc-simple could maybe have its own implementation to avoid overhead
2. Should we make the thread-unsafe version more lightweight and drop a bunch of dependencies?
3. How are we going to fend off the growing usage of nightly features?
4. Should we implement a basic copying/compacting collector
   • Maybe just jump straight to a generational GC?
5. Should the (future) generational GC be flexible enough to replace the simple collector?
   • The 'simple' implementation would be zero nursery generations with no copying
6. Which implementations should block the acceptance of this PR and remove the old zerogc-simple implementation?

To be clear, all of this will come before the release. zerogc v0.2.0 is gonna be big!

TODO: Get more comprehensive tests.

[Techcable]

I do want to refactor this in the future, but I no longer believe it's feasible to share allocation codee between collector implementation (different thread-safety configurations are of course a different story).

Collection and allocation are too closely coupled for meaningful abstraction. This is as it should be.