Intercept and rewrite ApiVersionsResponse to prevent negotiation of API keys that kafka-proxy doesn't support

[justinrlee]

Split #184 into two separate PRs:

• Add support for metadata response v13 (added in AK 4.0 as part of KIP-1102) (Support Metadata Response v13 #193)
• Add API key version limiting (separate PR) (Intercept and rewrite ApiVersionsResponse to prevent negotiation of API keys that kafka-proxy doesn't support #194) <- This PR

Example scenario:

• Client supports Metadata (3) Request/Response v14
• Server supports Metadata (3) Request/Response v14
• Kafka Proxy only knows how to parse and rewrite Metadata (3) Response v13

Prior to this change, this is the workflow (through KP)

• Client submits ApiVersions Request to Broker (passed through KP)
• Broker responds with ApiVersions Response to Client, including Metadata(3) v14 (passed through KP)
• Client sees that both client and server support Metadata(3) v14, and sends Metadata(3) Request v14 (passed through KP)
• Server responds with Metadata(3) Response v14 (intercepted by KP, and dropped on the floor because KP doesn't know how to parse it)

Post this change, this is the workflow (through KP):

• Client submits ApiVersions Request to Broker (passed through KP)
• Broker responds with ApiVersions Response to Client, including Metadata(3) v14
• KP intercepts ApiVersions Response, sees Metadata(3) v14 in the list of supported API Versions, and rewrites it to Metadata(3) v13 before sending it back to KP
• Client sees that broker 'only' supports Metadata(3) v13, and sends Metadata(3) Request v13 (passed through KP)
• Server responds with Metadata(3) Response v13 (which KP rewrites with new advertised listeners)

Note: depends on #193