Change default recycler pool to newConcurrentDequePool() in 2.18

[cowtowncoder]

(note: follow-up to #1256)

Altho we will revert back to ThreadLocalPool for 2.17.1 and rest of 2.17.x, we do want to move away in 2.18.
Let's use "ConcurrentDequePool" (via JsonRecyclerPools.newConcurrentDequePool()) as that seems to behave better and have otherwise similar approach as shared-lock-pool, but without potentially failing acquire that can lead to imbalanced handling & ever-growing pool.

[cowtowncoder]

Actually. Given all the feedback received so far, it appears that the ThreadLocal-based pool still performs best for pre-Loom threading. So let's postpone this change to 3.0 (master); will revert this change

[marlonpatrick]

ThreadLocal-based pool still performs best for pre-Loom threading.

@cowtowncoder I would really appreciate it if you could clarify some doubts for me:

1- What about an application using virtual threads? Did you notice any problems with newConcurrentDequePool() when used in conjunction with virtual threads?

2 - In the 3.0 release, you think the default will be newConcurrentDequePool() or you are considering another alternative?

3 - For Jackson 2.17.x, is newConcurrentDequePool() the recomended approach with virtual threads?

[cowtowncoder]

I have no experience on virtual threads myself, unfortunately: I hope others (like @mariofusco ) can comment here. With that:

1. Cannot comment
2. Not certain yet but that is my inclination
3. I think so, but have not really seen much information on people actually running with it.