Design notes

• Object pool implementation is thread safe, but not lock free so it is not suited for high frequency multi threaded access.
• To avoid issues caused by exceeding hard allocation limits, the pool always returns an object and stores only up to maximum capacity of objects. It is assumed that the developer will anyway have to profile the application to avoid potential memory leaks or excessive allocations.
• Pooled object is wrapped in a disposable to make sharing of pooled object easier without sharing the pool it self. Wrapping also prevents duplicate entries of same object being returned to the pool.
• Pooled object is not disposed on finalization, meaning that if consumers don't return the pooled object explicitly it will be garbage collected. I opted out of implementing disposal on finalization since I am unsure how to handle the case when both the pool and the pooled object would be finalized.