I think this fixes issue eventmachine#441.

8b613d0 changed the `select` timeout to zero in the case where
NumCloseScheduled > 0. It seems that in certain circumstances (for
example, if `close_connection` is called in a connection's `unbind`)
NumCloseScheduled would get incremented twice, but only decremented
once, thus never again reaching zero for the lifetime of the reactor.

The user-observed effect was that one CPU core would be pegged at 100%,
because the zero `select` timeout caused us to go around the select loop
without any pause.

Changing it so that it is safe to ScheduleClose() multiple times seems
like the cleanest solution to the problem.