GODRIVER-4018 Reduce allocations when building write batches

[paveon]

GODRIVER-4018

Summary

Pre-size the output buffer once in Batches.AppendBatchSequence and
AppendBatchArray instead of letting the per-document append grow it by
repeated reallocation. A first pass totals the documents that fit within the
maxCount/totalSize limits, dst is grown a single time, then the documents
are appended; when dst already has capacity the reservation is a no-op.
AppendBatchArray also now writes each element's numeric key in place with
strconv.AppendInt rather than allocating a string via strconv.Itoa.

Behavior is unchanged: same number of batches appended, byte-identical output,
same limit handling, and the same empty-result early return.

Background & Motivation

Both methods build the write payload for write operations (BulkWrite,
InsertMany, etc.) by appending each encoded document to dst in a loop with no
pre-sizing, so append grows dst geometrically — each growth reallocates and
copies the whole buffer accumulated so far. On large batches this is significant,
avoidable allocation churn and GC pressure, and it showed up as a top allocation
site in a profile of a write-heavy service. Document sizes are known up front, so
the capacity can be reserved in one shot; the limit-checking logic is unchanged.
The array path additionally allocated one key string per document. Minimum Go is
1.19, so slices.Grow is not used.

Benchmark (1000 × 256-byte documents, appending into a fresh buffer):

Function	allocs/op	B/op	ns/op
AppendBatchSequence	24 → 3	1,186,945 → 262,169	~130,000 → ~29,000
AppendBatchArray	925 → 3	1,189,861 → 262,169	~166,000 → ~38,000

[matthewdale]

@paveon Thanks for the improvement! The Go Driver team is at capacity right now, but we've scheduled reviewing your PR after some pressing work. Someone from the team will review it in about a month.