* also added basic test suite for the implementation

sr: refactor DialTLSConfig option so it is stored in client

This fixes a bug that has existed in this codebase forever, and only
now finally can occur.

In Kafka 2.4, Kafka introduced KIP-511, bumping ApiVersion to v3.

I misread the KIP and assumed that the broker would send ALL API keys
when the broker did not understand the version of the ApiVersions
request we were sending.

In franz-go, if the client detects an UNSUPPORTED_VERSION error,

* Brokers pre 2.4 would outright send nothing; we would downgrade our
  request to v0 and retry. This worked.

* Brokers post 2.4, I deserialized the response as v0 and assumed I had
  all keys.

As it turns out, the broker returns only _one_ key, which is the version
of ApiVersions that the broker supports. This would allow the client to
re-request ApiVersions with the highest version the broker supports.

This was never a problem until Kafka 4, which finally bumped ApiVersions
to version 4. The client now sends v4. The client would get
UNSUPPORTED_VERSIONS, unmarshal as v0, and only have one key set.

Now, we unmarshal as v0 and then re-request as whatever version the
broker says it supports.

This also adds a github action to test against Kafka 3.8, which should
prevent regressions as the library moves further and further into the
future.

Closes #1009, #1010.

kgo bugfix: ApiVersions replies only with key 18, not all keys

changelog: update for v1.19.1