Use a Drop trait to keep track of lifetimes for recycled objects.

[aeyakovenko]

• Move recycler instances to the point of allocation
• sinks no longer need to call recycle
• Remove the recycler arguments from all the apis that no longer need them
  update for recyclering #1250

[garious]

Results of my research with the lifetime-aware recycler:

• On it's own, it works extremely well, but requires lifetime-aware thread handles (i.e. crossbeam::ScopedJoinHandle).
• crossbeam gotcha 1: Unlike ScopedJoinHandle, can't pass its JoinHandle across thread boundaries. That's an artificial dependency in our codebase (we spin up a separate thread for each Fullnode to workaround Fullnode not starting asynchronously) but still a red flag. How is the standard library ahead of crossbeam in that regard?
• crossbeam gotcha 2: When I changed BankingStage to use ScopedThreadHandle, some tests would hang, suggesting the lifetime of Fullnode could be extended in surprising subtle ways, presumably by referencing a parent scope (maybe borrowing a string?).
• Rust gotcha: Once you add an explicit lifetime, it's lifetimes all the way up. You can't tuck it away in just the parent struct. It needs to be added to its parent struct and so on.

My vote is that we move forward with this PR - that implementing the Drop trait is the best bang for the buck. Some next steps might include:

• Removing the Arc and RwLock from Recyclables. The RwLock probably isn't needed at all and you should only mutate the recyclable after its moved out of the landfill. After that, all our uses of them should be readonly. The Arc is probably only needed before adding the Recyclable to a window. It should hold one reference, and the downstream stage should hold the other. The order those stages drops Recyclables is nondeterministic, so an Arc is the right tool for the job - it just doesn't need to be part of the Recycler!

[garious]

Merging this sooner than later because of the rebasing that'd be needed otherwise.