Make ScheduleClose() idempotent

I think this fixes issue #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.
Merge pull request #445 from ept/double-close

Make ScheduleClose() idempotent
correct reactor_running? to return false after a process running a reactor forked
Merge pull request #455 from SamSaffron/master

Correct reactor_running? to return false after a process forks