Add headers to consumed/produced records

[sigevsky]

Closes #58

Implementation details

1. I'm using [rd_kafka_produceva] (https://github.com/edenhill/librdkafka/blob/master/src/rdkafka.h#L4397) bindings (which is identical to rd_kafka_producev, besides structure passings instead of varargs) as regular rd_kafka_produce message doesn't support headers. This requires at least 1.5.0 librdkafka version: producev without varargs confluentinc/librdkafka#2895
2. rd_kafka_produce_batch does not allow passing headers as well so I left ProduceRecord as is. Instead I've added a separate produceWithHeaders to cover the case when singular message is produced with headers.
3. Consumer record now has crHeaders field which is a breaking change, but I don't really see how this can be done differently without duplicating the existing api.

[sigevsky]

@AlexeyRaga could you help me with pipeline/review?

[AlexeyRaga]

Thanks! It is really great to see movements in this direction.

TBH, I think that we should just drop batch producer from the library. I am saying this based on this conversation with Magnus (the author of librdkafka)

This would allow us to simplify the producer, add headers to the message type, clean up the story about delivery callbacks, etc.

What do you think?

[AlexeyRaga]

The specification says:

 * @returns RD_KAFKA_RESP_ERR_NO_ERROR if headers were returned,
 *          RD_KAFKA_RESP_ERR__NOENT if the message has no headers,
 *          or another error code if the headers could not be parsed.
 *

Can we return Left in case of that another error code instead of failing with an error?

[sigevsky]

I think you are citing rd_kafka_message_headers doc (this case is handled a bit higher) whereas this code corresponds to rd_kafka_header_get_all which has the following constraints for its return value:

 * @returns RD_KAFKA_RESP_ERR_NO_ERROR if an entry was found, else
 *          RD_KAFKA_RESP_ERR__NOENT.

[AlexeyRaga]

I think that it can be an overlook at librdkafka documentation side because handling "if the headers could not be parsed" in another looks strange.
But OK, we can fix it later.