Potential connection leaks caused by the connectivity check

Historically, for a TTransport, IsOpen returns false means that the connection is already explicitly closed. So third party code (for example, client pool management logic) could just throw the connection away after IsOpen returned false without worry.

But since the adding of connectivity check in go library (first release version 0.14.0), that is no longer true: IsOpen could return true when the remote closed the connection, and in such cases Close shall still be explicitly called. If we just throw the connection away without explicitly calling Close, the action of "throw away the connection" will cause connection leaks.

There are 2 ways to mitigate it:

1. Document in IsOpen that IsOpen returning false does not necessarily mean the connection is already closed, and an explicit Close call is still needed.
2. Implicitly call Close inside IsOpen when connectivity check fails. This way we keep the assumption that IsOpen returns false means Close was already called being true.

Duru Can Celasun what's your preference between the 2 paths?