Optimize garbage collection

In the discussion about performance improvements (#50), a point that arose repeatedly is the impact of the `crossbeam_epoch`-based garbage collection we use to track map entries (nodes and values).

There are several angles from which we might look at reducing this impact. This issue is meant to be for discussion and changes around how and when our code interacts with garbage collection. Ideas floated in https://github.com/jonhoo/flurry/pull/72#pullrequestreview-378586231 and previous comments may serve as a starting point. They include:
* moving direct interactions with `crossbeam_epoch`, e.g. in the form of `defer_destroy`, out of critical sections in favour of a simpler collection mechanism for things to be deleted. The collected entities could then be handed of to garbage collection _after_ dropping the lock for the critical section.
It is yet unclear whether this would yield a significant improvement over calling `defer_destroy` directly from within the critical section (as happens currently), as crossbeam essentially also [stores a closure for the drop](https://docs.rs/crossbeam-epoch/0.8.2/src/crossbeam_epoch/guard.rs.html#271-273) and takes some measures to optimize the storage of these closures (for example, a deferred closure only requires a heap allocation if it exceeds a certain size).
* optimizing `defer_destroy` and its usage itself. See again https://github.com/jonhoo/flurry/pull/72#pullrequestreview-378586231