Ensure transport closed info is always handled properly

[irisTa56]

This PR restores the behavior prior to 1.4.0, where arriving tcp_closed info triggers ondisconnect/2 callback regardless of the client's state.

Problem

In versions 1.4.0 and later, the ondisconnect/2 callback is only triggered in the connected and handshaking states.
This change prevents the callback from being invoked if tcp_closed info arrives after receiving a Close frame.

Additional Explanation

While it may seem counterintuitive to expect tcp_closed info in the disconnected state, this happens because the client enters the disconnected state after receiving a Close frame (and before the connection is actually closed).

An ideal approach might be introducing a new state, which partially corresponds to the CLOSING state stated in RFC 6455 (related to #17).
However, since such change should be done in accordance with #62, I chose to restore the previous behavior.