Fix hypothetical consumer deadlock, attempt 2

[eapache]

Fixes bug #475

Should be correct in all cases, unlike #483.

@Shopify/kafka

[eapache]

As I should have realized when the original ticket confused willem, the over-use of dying was the root problem. That value doesn't need synchronization, so just put it as a normal member.

[wvanbergen]

- this looks a lot easier to understand as well 👍

[horkhe]

@eapache @wvanbergen this change introduce a race over closing the dying channel. So PartitionConsumer.Close() may fail with panic: close of closed channel. And that is the reason why a build of #492 failed after rebase to master.

[eapache]

In my opinion that test is broken: it is user error to call Close or AsyncClose on a consumer after it has already closed, which it must have done because the Messages channel returned !ok.

[horkhe]

Consider this:

select {
case msg, ok := <-pc.Messages():
    if !ok {
        break // The consumer is closed
    }
    pc.Close() // Panic!!! because the channel was closed right after we checked the channel
}

[horkhe]

In other words since there is no atomic operation checkChannelAndClose the Close() operation is not reliable anymore.