Seeker refactoring and simplifications

[richardartoul]

The seekers have a concept of a ConcurrentClone() which creates a low cost clone of a seeker so that the SeekerManager can maintain one per read concurrency. This was originally included in the design as the Seeker contained a lot of state that was not safe for concurrent access.

With recent improvements / refactorings to the Seekers there is very little state left in the seekers themselves. Its likely that the concept of a ConcurrentClone could be removed entirely which would simplify the codebase and be a little cleaner generally.

In addition, the Seeker has a concept of an unreadBuf that can be set by an external caller. With the recent introduction of ReusableSeekerResources there is no reason to maintain the unreadBuf and the unreadBuffer() and setUnreadBuffer() methods. Any reusable or shared buffer can simply be included in the ReusableSeekerResources() which is provided as an argument for all relevant function calls.

[robskillington]

+1 to all these changes (as long as we don't introduce per operation allocations).