Optimize with runtime.AddCleanup + more benchmarks

[lemire]

I am fairly happy that this PR could serve the basis of our first release.

Here is what grok tells me about the change:

runtime.AddCleanup is significantly more performant than the legacy runtime.SetFinalizer primarily because it avoids object resurrection. With SetFinalizer, the finalizer function receives the object itself as an argument, which forces the garbage collector to keep the object (and everything it references) specially reachable until the finalizer runs — often requiring at least two full GC cycles before the memory can actually be reclaimed, and causing extra work for the GC's mark phase. In contrast, AddCleanup passes a separate argument (arg S) to the cleanup function and never passes the original object, so the GC can immediately treat the object as unreachable and reclaim its memory in a single cycle, even when the object is part of a reference cycle. This design eliminates unnecessary GC overhead, reduces latency in memory reclamation, supports multiple cleanups per object without additional cost, and results in roughly 2x better performance for the registration and cleanup path compared to finalizers (while still being slower than pure manual deallocation). Overall, it leads to lower memory pressure, fewer GC pauses, and more predictable resource management in long-running Go programs.