[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).

Commencez par lire com.click house.client.api.internal.HttpAPIClientHelper et retracez la manière dont le client configure actuellement Apache HTTP Client. Cartographiez les limites des requêtes SQL, des paramètres du serveur et des requêtes, ainsi que du contexte d’authentification, y compris les paramètres d’initialisation. Le travail est terminé lorsque l’abstraction de transport et son implémentation enfichable via Service Loader sont définies pour les cas d’utilisation décrits.

Rédigé par le modèle d'indexation à partir du texte de l'issue.