Performance: Asynchronous garbage collection

[cjpatton]

Whenever a DO instance is created, the name of the instance is sent to GarbageCollector so that the instance can be scheduled for deletion.

Centralizing garbage collection in this fashion has two major downsides:

1. DO->DO communication incurs noticeable latency for the request that initiated it
2. There is a risk that that the garbage collector won't keep up with the rate at which garbage is created.

@oliy suggests a different approach, which ought to scale better. Once cloudflare/workers-rs#189 lands, we can have new DO instances schedule an alarm to delete themselves when they're no longer needed:

• HelperStateStore is needed only for the aggregation sub-protocol. This would be safe to expire after, say, an hour.
• ReportStore is probably safe to expire after, say, a few days. We'll have to coordinate expiration with the Leader/Helper behavior, since we'll need to reject reports that correspond to expired ReportStores.
• AggregateStore will require some thought. Certainly this should not retire before ReportStore. It may be safe to keep these around for months, given the relatively low volume. Perhaps it's acceptable to garbage collect these as usual?
• LeaderAggregationJobQueue, LeaderCollectionJobQueue -- We should probably leave as-is until we've thought through Scaling up the Leader #25.

[cjpatton]

Closing this ticket since we basically know what our plan is here.