Make sure push_read_back results in the event being ready.

If you push back read data from a socket and it is subsequently idle,
you need to push the data back to a buffer and mark the event as having
data ready to read somehow.  There is already a facility for Danga's
PostEventLoop() function to be called, which is supposed to clear these
synthetic read events.  However, a bit wasn't set on the tasks' list of
interesting events, and this caused the pushed back data not to 'wake
up' the task and continue.  So, set the bit in the right place.
Add the one test from Danga::Socket that runs under this implementation.
Prepare to release version 0.2.
Avoid a booby–trapped function

For some reason, we're seeing this error using Perlbal in 'selector'
mode with AnyEvent:

   Shouldn't get here!  This is an abstract base class, pretty much, except in the case of the 'selector' role. at .../env/lib/perl5/Perlbal/ClientHTTPBase.pm line 290
   Perlbal::ClientHTTPBase::event_read('Perlbal::ClientHTTPBase=HASH(0x318d5c0)') called at .../env/lib/perl5/Danga/Socket/AnyEvent.pm line 448
   Danga::Socket::PostEventLoop() called at .../env/lib/perl5/Danga/Socket/AnyEvent.pm line 493
   Danga::Socket::__ANON__() called at .../env/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Loop.pm line 233
   AnyEvent::Loop::one_event() called at .../env/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/Perl.pm line 46
   AnyEvent::CondVar::Base::_wait('AnyEvent::CondVar=HASH(0x3164898)') called at .../env/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent.pm line 1981
   AnyEvent::CondVar::Base::recv('AnyEvent::CondVar=HASH(0x3164898)')
   ../env/lib/perl5/Danga/Socket/AnyEvent.pm line 369
   Danga::Socket::EventLoop('Perlbal::Socket') called at .../env/lib/perl5/Perlbal.pm line 1364
   eval {...} called at .../env/lib/perl5/Perlbal.pm line 1362
   Perlbal::run() called at .../bin/prog line 212

This recent change could be the cause.  This implementation is a bit
of a hack but without knowing much more about Perlbal it'll have to
do.
Fix another obscure hanging client bug

The previous change was not correct, not least because it mis–spelled
"event_read" as "read_event" and would emit uninitialized warnings.
It was only ever a temporary solution :-).

No, its main mistake was to think that just masking that bit before it
is about to blow up is the right time.  The problem was that an
earlier event never woke up; reads, which are disabled the first time
through Perlbal::ClientHTTPBase::event_read, are later re-enabled
during Perlbal::Service::adopt_base_client, when it calls
Perlbal::Client::new_from_base ("base" here referring to the object
before it is re–blessed into a derived selector class).

This module's watch_read function, which is monkeypatched into
Danga::Socket, sets up an AnyEvent io event watcher on reads; but in
the case where synthetic reads ("push_back_read") are in effect, this
event will never fire.  This case can be detected, and the bit flipped
as in a previous change.
Fix another crash with pushback data

If the event is forwarded to a selector, but the selector doesn't
adopt itself out to anything, then it is important that reads are
ignored, including synthetic reads.  Clear the POLLIN flag when there
is push back data.  It might be required to clear it in other
situations, but for now keep the change minimal.