Optimizations for ResourceAwarePool

[kab163]

• Create a release_pending function so that users can specify whether they want the current behavior of release (it will only release free chunks) or the this new behavior which would wait for and release pending chunks in addition to free chunks
• Think about editing the getNumPending function to include a check on the events. This way it is the most up-to-date counting of pending chunks. Currently that function is only used in testing
• Implement a pending_list_it iterator to make the do_deallocate for a finished pending chunk cleaner with less redundancy. Currently we loop thru the pending list, find the first pending chunk that is now done, and then call do_deallocate on it. That will invalidate the iterator so we have to break out of that loop after the first one. If we instead use an iterator to keep track of it, we could do this more cleanly and search thru the entire pending list
• Say I allocate ptr with camp resource d1, then it will throw a runtime_error if I try to deallocate ptr with d2. This is the correct behavior. But, if the next thing I try to do is deallocate the ptr with the correct resource (d1), then umpire throws an error that that pointer "cannot be removed" (an AllocationMap error). I guess somewhere in umpire it "counts" the deallocation as having gone thru even though it really didn't. This would normally not be an issue, but it is for testing.