sr: add `Client.OptValue` and `Client.OptValues` functions

* update all requests to latest kafka 4 stuff -- most have no new
  behavior (for only the supported requests!)
* bump deps

kfake: updates

It includes 3 new client options to set the
logger function and the logger level.

It mirrors kgo's Logger and LogLevel definitions,
making it easy to use any existing kgo logging
functionality you may already be using in this
package as well.

sr: Add logger function to schema registry client

Code in 2020 assumed that handleReqResp would only read a few safe
fields forever. Code added in 2022 started reading fields from cursor,
which could be modified concurrently when handling a metadata response.

There is little reason to run handleReqResp independent of a fetch
session -- there is minimal CPU blocking.

By handling responses inline in a consumer session, we can be
*guaranteed* that there is no race with metadata handling (or other
things) since an active consumer session blocks concurrent updates that
would affect the consumer session.

Closes #1018.

Kafka introduced "features" in the ApiVersions response a long time ago
during Kafka 2.6. This was never used in clients, and I did not add
support for features to franz-go.

Well, Kafka 4.0 finally started using features in clients.

KIP-890 -- which does not mention the exact feature name
"transaction.version" -- requires clients to only opt into "part 2" of
the KIP if transaction.version >= 2.

What this means is that if you were talking to Kafka 4 but had not yet
enabled transactions in the cluster, transactions would not work.

I audited a bit of the Java client code and discovered a few other
things that I hadn't implemented -- for these, I point to the lack of
actually calling out protocol version bumps in the KIP and mentioning
the changes in like, 5 words:

* AddOffsetsToTxn is no longer sent if we use TxnOffsetCommit v5+ (same
  principle as AddPartitionsToTxn not being sent for Produce v12+)

* TxnOffsetCommit is pinned to v4 unless we detect kip890p2

* EndTxn is pinned to v4 until we BEGIN a transaction with kip890p2

* If we end and were pinned to v4 but then detect the cluster supports
  kip890p2, we re-init our producer ID (Java client does this to
  simplify things as we opt into p2)

* Produce is pinned to v11 if we are transactional and kip890p2 is not
  supported (same as Java client)

Closes #1017.

Well, we support transaction.version v2 now...

Bugfixes