Allow checking the entire ProducerMessage in the mock producers

[joewreschnig]

This is done by introducing MessageChecker, a function which validates
an entire ProducerMessage, and reimplementing the existing expectation
interface on top of that. Since producerExpectation was not a public
API, the only visible effect of this to users of the mock producers
should be slightly different error messages when encoding fails.

To better mimic the real producers’ behavior, this also runs
partitioning before passing the message to the checker. By default all
topics have 32 partitions but this can be configured per-topic in either
producer via the embedded TopicConfig. (This does not allow mocking
unavailable partitions; I don’t see a use case for this which can’t be
better handled by unit testing the partitioner.) This may affect
existing tests if someone was passing a configuration with a
Partitioner that would fail on their test messages, but it seems more
likely they want to know if this is the case (we did).

This is useful for (at least) two reasons,

• I would often like to test more than just the message value; services
  may need to produce to different topics or with specific partitioning
  schemes. In some cases valuable data may only be in the message key,
  or I want to test that a header and message body agree.

• Since the topic usually also corresponds to the data format, exposing
  the topic makes it easier to collect messages of different types
  across different topics which may appear in known quantities but
  non-deterministic orders. Without the topic this is only possible by
  trying to content-sniff the format from the value, which leads to
  weaker and more fragile tests.

[joewreschnig]

After filling out the CLA it asked me to re-run the CI check but don't see how to do that. I don't think I can until I'm approved to run workflows.

[joewreschnig]

Sorry, I can't see anything actually broken in the CI, nor a way to trigger a retry myself. Given exit code 28 in the 1.16/2.7.1 case it seems like curl might have timed out trying to install golangci-lint. I ran v1.37.1 (and various other versions) locally with 1.16 and saw no errors.

[dnwe]

Thanks for the first-time contribution @joewreschnig !

These changes look good to me — thank you for the detailed description