memorypool: remove custom arc in favor of system allocator

[jkarneges]

Like our custom Rc, we have a custom Arc that works with a preallocated memory pool. After lookng into the performance of our custom Rc vs std, I believe our custom Arc can't be any faster than simply using the std Arc with the system allocator, and we should remove it. This PR does that, replacing all usage with std.

I didn't benchmark our Arc against std, but it's enough to compare the code. Std uses raw pointers (notably Deref is a direct pointer deref) whereas we protect all operations with a Mutex. Given that our Rc's earlier use of RefCell was too much overhead to compete with std, a Mutex has no chance. Further, our Arc is currently only used to manage instances of zmq::Message which is a small Vec-like type, and the system allocator performs very well with small types, at least on Linux with glibc. So, it should be safe to switch to std without consequence.

Yes, possibly our Arc could be optimized to use raw pointers like I did with our Rc. However, Arc is much harder to get right, and the benefits are unclear for our current usage (small types). Removal is an easier solution.

We could potentially change our Arc to wrap std instead of removing it, to make it easier to reintroduce pooling in the future. However, since we are currently only pooling zmq::Message and not the (more significant) actual content of those messages, my sense is if somday we want to do pooling in this area of the code then it deserves a full rethink anyway, and so in the present I lean toward removal.