[client-v2] Abstract a Transport Layer

### Description
The current client implementation is built on top of the Apache HTTP client, which is configured internally by "com. click house.client.api.internal.HttpAPIClientHelper". This keeps things under the client's control and prevents users from misconfiguring the HTTP client.
However, some use cases may need to control the whole configuration of the HTTP client (security, performance considerations).
A series of changes is required to achieve the goal:
- Define boundaries and data crossing them between the client and a transport layer abstraction. The client mainly operates with SQL queries, server settings, request settings, and authentication context. Protocol defines how these things apply at the transport level. For example, server settings in HTTP are part of URL query parameters and authentication is part of headers. The transport layer should be able to translate a client request into understandable entities and apply them to a network request.
- Define a way in which transport abstraction is initialized. The main challenge is in passing settings. For example, connection request timeout for Apache HTTP Client, but not default server settings (applied when a request is made).
- Implement loading transport implementation pluggable with Service Loader. This is important to support use cases when the user has limited control of how the client is configured and instantiated (typically BI tools).

Start by reading com.click house.client.api.internal.HttpAPIClientHelper and tracing how the client currently configures Apache HTTP Client. Map the boundaries for SQL queries, server and request settings, and authentication context, including initialization settings. Done means the transport abstraction and its pluggable Service Loader implementation are defined for the described use cases.

Written by the indexing model from the issue text.