Fix #1114: make BufferRecyclerPool generic

[cowtowncoder]

PR to implement #1114 by rewriting BufferRecyclerPool, implementations so that there are:

• Abstract base types for recycling any types (not just BufferRecycler)
• JsonFactory-specific subtypes, implementation classes that pool BufferRecycler values.

Will add new container class JsonBufferRecyclers for latter, keep BufferRecyclerPool for former.
Will not yet rename BufferRecyclerPool but may consider it as follow up.

[cowtowncoder]

Will probably consider renaming of BufferRecyclerPool as it'll allow recycling other things, but initially leaving name as-is to simplify merging to master.

[cowtowncoder]

Will move BufferRecycler-bound implementations here next.

[mariofusco]

@cowtowncoder I saw what you did and I agree with this change.I also originally implemented the pool in a generic way because I "felt" it was the right thing to do, but then I reverted it.

I also checked that this works fine with the quarkus integration that I'm attempting. By the way we would need the stable 2.16 asap in order to start using the pool also on our side, do you have any on when it will be released?

[cowtowncoder]

@mariofusco I have been about to send an email about 2.16 plans. Things are quite close to getting RC1 out; I just have one feature I really want to get in jackson-databind before that. So if all went well, could get RC out in 2-3 weeks. And this time around only doing one -- seems like few devs really use release candidates anyway. RC1 should have recycler pool thing finalized wrt API (unless issues were found from within).

Also: I (or someone else) need to work on using now-generic pools to replace existing ThreadLocal based hard-coded reuse on Smile, Avro and... JAX-RS module? Ideally would tackle for 2.16.

[cowtowncoder]

Making good progress on "last" issue to resolve (databind , then FasterXML/jackson-databind#4096); email sent.
But maybe I'll get to doing RC1 during next week.