Follow-up to https://github.com/celery/py-amqp/pull/328/, this removes an out of date comment.

`frame_writer` allocates a `bytearray` on intialization with a length based on the
`connection.frame_max` value. If `connection.frame_max` is changed to a larger value, this causes an
error like `pack_into requires a buffer of at least 408736 bytes`.

From what I can tell, `connection._on_tune` can arbitrarily change this value, although I'm not
totally sure in what cases it actually occurs.

For context, we're upgrading from Celery 3.1.25 -> Celery 4.1, librabbitmq 1.6.1 -> amqp 2.6.0,
kombo 3.0.37 -> 4.2.2.post1. This has worked fine in a small production environment, but fails on
our main deployment. The main culprit we see are lots of errors with `pack_into requires a buffer
of at least <x> bytes`, where x is always larger than our default `frame_max` of 131072. Despite
this, `bigbody` is False, which ends up with us attempting to write a frame that is too large into
the existing buffer. The only way I can see this happening is if `frame_max` increases.

* Don't default content_encoding to utf-8 for bytes

This is not an acceptable default as the content may not be
valid utf-8, and even if it is, the producer likely does not
expect the message to be decoded by the consumer.

* Fix encoding of messages with multibyte characters

Body length was previously calculated using string length,
which may be less than the length of the encoded body when
it contains multibyte sequences. This caused the body of
the frame to be truncated.

* Respect content_encoding when encoding messages

Previously the content_encoding was ignored and messages
were always encoded as utf-8. This caused messages to be
incorrectly decoded if content_encoding is properly respected
when decoding.

The function returned by frame_handler is meant to return True
once the complete message is received and the callback is called,
False otherwise.

This fixes the return value for messages with a body split across
multiple frames, and heartbeat frames.