demonstrate the race between r_c_vnode_worker_pool and poolboy's fsm

As described in #298:

When a riak_core_vnode_worker finishes work, it sends checkin messages
to both poolboy and riak_core_vnode_worker_pool. The latter maintains a
queue of work to be handled when there's room in the pool. As soon as
RCVWP gets the checkin message, it asks poolboy if there is a worker
available (expecting that the worker just checked in will now be
available).

The problem is that poolboy may receive RCVWP's message before receiving
the worker's checkin message. If this happens, it will tell RCVWP that
the pool is full. RCVWP then sticks in the 'queueing' state until it
receives another checkin message from a worker. Since another checkin
may never arrive, the pool may become frozen.

Crashing workers create a similar race condition to the double-checking
case, because 'DOWN' messages are delivered to both
riak_core_vnode_worker_pool and poolboy. RCVWP again asks poolboy to
checkout a worker (effectively immediately), which might happen before
poolboy receives its 'DOWN' and starts a replacement.

The test defined by worker_pool_pulse.erl demonstrates these races.
Under PULSE execution, the test will fail with deadlock. If it fails for
another reason (like timeout) you may have missed one of the
requirements described below.

In order to run the test, you will need the pulse_otp beams from
https://github.com/Quviq/pulse_otp on your path. The riak_core and
poolboy applications, as well as the worker_pool_pulse module, must also
be compiled with the 'PULSE' macro defined. The newly-added 'pulse' make
target will do this for you (and also run the test), but you will need
to start with a clean checkout (no beams built), or recompilation will
be skipped.