`BufferRecycler` should avoid setting replacement if one already returned, bigger

[cowtowncoder]

(based on discussion FasterXML/jackson#204 -- good suggestion by @kkkkkhhhh)

It seems that BufferRecycler will always replace assigned buffer when release method is called. But it would probably make sense to only replace null or smaller buffer, and avoid replacing bigger buffer with smaller.
While in the original expected usage sequence should always be "alloc / release / allow / release" (in which case "release" would be replacing null), there can be cases where this does not hold (multiple parsers/generators per thread, concurrently; but also just parser-and-generator case).

So let's add some basic checking into release method.

[cowtowncoder]

Note: in multiple-allocation case there is no real guarantee that the oldest buffer would be retained. Fix just helps to ensure the longest buffer chunk is retained.

But instead of trying to retain oldest buffer at this level we should migrate to newer RecyclerPool implementations (ones not based on ThreadLocal) as they will also better support multiple-instances-of-buffer-per-thread case, in addition to other benefits.