Closing a tap with a pending item blocks the mult input channel

Comment made by: klauswuestefeld

A more general case:

Doing this:

(go (println (>! c 42)))

and then closing c will cause the >! to block, instead of returning false.

If c is closed before that, >! will return false.

Is this race condition the intended behavior?

As far as I could understand, the `close!` implementation follows all `take`s and run their respective callbacks for releasing.

The approach I follow was doing the same for `put`s, so we guarantee previously parked `put` will be release - like demonstrated by the general case of this error.

In the same patch, I added a single test to assert this behavior and ported the same code to ClojureScript implementation. I could split both impls on different patches, but I judged having everything together will ease the screening.