Add Baichuan.send_binary() for talk/audio streaming

[matthewholm]

What

Adds Baichuan.send_binary(): sends an encrypted extension XML followed
by a raw, unencrypted binary payload in a single message.

Why

send() always encrypts both the extension and the body, so it can't
express the framing some Baichuan commands need — an encrypted header
immediately followed by raw binary data that must reach the camera
unencrypted. cmd_id 202 (two-way talk audio) is one of these.

Without this, a caller has to reach into private internals
(_connection, _mess_id, _aes_encrypt, receive_futures) to build
that framing by hand — which is exactly what I had to do in a downstream
Home Assistant integration adding two-way talk support for Reolink
cameras behind a Home Hub/NVR. That approach is fragile: those
attributes aren't part of the public API and can change without notice
between reolink_aio releases.

send_binary() builds the same on-wire header send() does, encrypts
only the extension, and reuses the existing connection.send() for
transmission and ack-matching — no changes to the connection layer.

Testing

Validated against a real Reolink Home Hub + battery camera over
several weeks in production use (one-shot TTS playback and live
streaming push-to-talk), via the downstream integration linked above.

CI (pylint, flake8, isort, black, mypy) passes on all four Python
versions in the test matrix.

[matthewholm]

Closing in favor of #165, which implements the same underlying binary-payload framing as part of a much more complete talk API (start_talk/send_talk_data/stop_talk) with full test coverage. No need for two overlapping PRs -- I'll add my real-world validation over there instead.