Keep amount of concurrently created resources bounded

[qnikst]

The problem

The library may have problem in case of multiple concurrent requests came in together.

In this case we will allocate many resources at once. In case if new resource creation is costly (for example TLS connection initialisation) this may stress entire system, and increate overall resource creation time. This problem is not theoretical and we have faced it multiple times in production both in cloud and on premise systems.

Proposed solution

As it's not possible to know in advance the good strategy for all kinds of resources system, I propose to add an extra option for createPoolEx that will set the upper bound on amount of concurrently created resources, with Unbouded as a default [1].

This solution should play well with issue #3, as we will need to track threads that creates resources in that case.

Discussion

1. Default value. For me Unbouded looks like a bad default choice, so user who didn't read the documentation may get in an emergency situation under unexpected load, however this way will preserve backwards compatibility, that is more relevant for the package.
2. Limit score. Should we set a limit for an entire Pool or for the LocalPool aka stripe. I would suggest to set limit for a stripe, but maybe there are other considerations?