GC: implement full kernel-side refcount management

[warner]

What is the Problem Being Solved?

Once the data feeds (dropImports) and actuators (dropExports) are in place, the biggest remaining subtask of #2615 will be to actually compute the unreachable objects and call dropExports for them.

The easier/cheaper piece of this is plain refcounting:

• when we're informed about a refcount being decremented, add it to a candidate list
• when we're done decrementing everything, process the list. for each item:
  • if the refcount is zero, find everything it used to point to, decref them, add them to the candiate list
    • then delete the item, and schedule it for a dropExports or something

The header/more expensive piece is to deal with cycles. The traditional approach is a full mark-and-sweep collector, but I'm worried about the expense of running that on-chain. @dtribble had an interesting idea: let an off-chain analysis tool compute the members of an unreachable cycle instead. It could submit a special transaction that says "I claim the following object/promise IDs form an unreachable clique". The kernel would then sweep the object graph starting from those points, to 1: make sure there are no edges pointing outside the cycle, and 2: make sure all the refcounts are accounted for by edges from within the clique. If both are true, the whole batch is deleted.

I'm also hopeful that there's some clever way to use bidirectional pointers to avoid any global mark-and-sweep operation, but I haven't sat down to consider the details.