(*PgConn).CancelRequest should support encryption

The CancelRequest method connects directly to the Postgres instance, ignoring TLS settings the connection was configured with. The PostgresSQL implementation indeed allows you to send unencrypted Cancel requests, but ideally we would support encryption similar to libpq ([libpq cancellation API docs](https://www.postgresql.org/docs/current/libpq-cancel.html)):

> Many connection parameters of the original client will be reused when setting up the connection for the cancel request. Importantly, if the original connection requires encryption of the connection and/or verification of the target host (using sslmode or gssencmode), then the connection for the cancel request is made with these same requirements. Any connection options that are only used during authentication or after authentication of the client are ignored though, because cancellation requests do not require authentication and the connection is closed right after the cancellation request is submitted.

Start at (*PgConn).CancelRequest and trace how the connection's TLS settings are stored and reused. Compare the behavior with the libpq cancellation API documentation, focusing on encryption and target-host verification. Done means cancel requests honor the original connection's encryption requirements.

Written by the indexing model from the issue text.