WL#3971: Avoid truncation in binary log

Suggestion from Guilhem:

Potential problem: in the binary log, we encode in 4 bytes values
("end_log_pos" for example) which can theoretically be a number larger
than 2^32. So there is a risk for truncation during
storing. Consequences of this truncation are not well known.

Probability: so far we got no bug reports. As RAMs get larger,
transactions get larger, so users may set --max-binlog-cache-size and
--binlog-cache-size to multi-GB values, making the problem more
likely. The introduction of row-based replication, which creates much
bigger binlog objects (a CREATE SELECT over a 10GB table creates a
10GB object), also makes the problem more likely.

Proposal: review the existing code to understand the consequences of
truncation, and what simple measures can be taken to avoid truncation
(put a hard-coded limit on max_binlog_cache_size? add a few if()s in
code?); also review if the IO_CACHE implementation (which is used by
binary logging and which is years old) is ready for caches larger than
4GB.

Regarding bug reports, there is one. It is bug #11762618 from new bug system, or
#55231 from bugs.mysql.com. This bugs fully justifies this WorkLog entry, as
well as WL # 6009. Both are based on the current constraint of 4 byte offset values.

Estimated time: 6 work days.