feat(rest): add faraday_config option to client configuration

[aandreassa]

Summary

Addresses issue googleapis/ruby-core-libraries#57.

While gapic-common already supports yielding the Faraday::Connection inside ClientStub, this hook was unreachable from auto-generated client libraries. This PR exposes that capability to the public client layer, enabling advanced HTTP customization like mTLS client certificate configuration.

Design

Instead of forwarding blocks through the client constructors (which collides with the existing configuration blocks), we introduce a config.faraday_config attribute.

This approach isolates transport specific details, allows clean automated propagation to internal subclients (LROs and mixins), and has a respond_to? check to preserve perfect backward compatibility with legacy gems versions.

Example Usage

client = Google::Cloud::Language::V1::LanguageService::Rest::Client.new do |config|
  config.faraday_config = ->(conn) do
    conn.ssl.client_cert = OpenSSL::X509::Certificate.new cert_pem
    conn.ssl.client_key  = OpenSSL::PKey::RSA.new key_pem
  end
end

[quartzmo]

This appears to be a significant escalation in formally exposing Faraday in the clients' public surface.

For many years, these clients have encapsulated Faraday without* externally binding themselves to its details.

Instead of exposing the raw Faraday connection, we could consider exposing specific configuration options for the required use cases (such as mTLS) and applying them to Faraday internally.

• The only other exposure I could find is where the TransportOperation object is yielded to users in the block of generated service methods. However, the reader underlying_op is marked as @private, and the docs warn that it is not guaranteed to be any specific type and its value is not guaranteed to be stable.