* 1.0.0
** Breaking Changes (upgrading from 0.0.x)
*** pooler application config format changes
Pool names in config must be atoms, not strings.
*** API changes
1. The function =pooler:take_member/0= has been removed.
2. Pool names are now atoms not strings. An atom matching a
   configured pool name is expected by =pooler:take_member/1=.
3. For load balancing a collection of related pools, you must use the
   new group API functions: =pooler:take_group_member/1= and
   =pooler:return_group_member/2=. A group attribute can be specified
   as optional config for each pool. Pools with the same group name
   form a group.
** What's New
*** Improved support for multiple independent pools
Each pool is now serviced by its own =gen_server= with an independent
supervision tree. This makes pooler a good fit when you need to pool
different unrelated clients, for example Redis and Riak. Independent
pools will not contend for the same server mailbox as was the case in
version 0.0.x and the supervision structure should isolate failures
such that a high crash rate in one pool should not take down an
unrelated pool.
*** Asynchronous and parallelized member creation
Members are started and added to pools asynchronously. This is a major
improvement when pooling members with substantial startup
time. Instead of the entire pool being blocked while a new member is
started, the pool can continue to process messages.

When a pool is initialized, all =init_count= members are started in
parallel. The pool does not start processing messages until all
initial members have been added. This reduces the overall
time-to-start for pooler compared to version 0.0.x where
initialization of members was handled serially.

Once running, new members are added in batches of size =init_count=
up to =max_count=. Batches are added after the pool returns a
single =error_no_members= value for a pool. This means a pool will
always return at least one =error_no_members= value when growing
beyond =init_count= size. This approach has the benefit of not
penalizing a steady load of =init_count= members in use. If members
addition were to be triggered before =init_count= were in use, then
members would be added to the pool, never used, and culled after the
configured timeout.
*** The pooler server uses monitors not links
In pooler 0.0.x, =pooler= was a system process that trapped exits and
linked to members and consumers. Monitors are now used instead to
reduce the potential impact of a pooler related crash and to simplify
the code.