Leak in unreleased code. Affects mongoc_cursor_new_from_command_reply and other command-to-cursor paths, possibly including "find" commands.

The problem with mongoc_cursor_new_from_command_reply goes like this:

mongoc_cursor_t *cursor;
bson_t *reply = bson_new ();

run_command (...., reply);
cursor = mongoc_cursor_new_from_command_reply (
   client,
   reply,
   server_id);
mongoc_cursor_destroy (cursor);

1. Create "reply" with bson_new. Its "STATIC" flag is unset to indicate this is heap-allocated.
2. Pass "reply" as an out-pointer to run_command.
3. run_command assumes reply is uninitialized. When it calls bson_copy_to to copy the command reply to the bson_t, bson_copy_to initializes reply, including setting its STATIC flag.
4. Pass reply to mongoc_cursor_new_from_command_reply.
5. When the cursor is destroyed it calls bson_destroy on the bson_t, but since its STATIC flag is set, only the bson_t's contents are freed, not the struct itself.

One solution is to stack-allocate "reply". But then the cursor must copy reply's contents in order to own them, which is a very expensive way to do every query. So in addition, we need:

/* moves src's internal buffer to dst, destroys src */
bson_copy_with_steal (bson_t *src, bson_t *dst)

This way, "reply" is stack allocated, run_command can correctly assume it's uninitialized and set its STATIC flag, and then mongoc_cursor_new_from_command_reply can take ownership of reply's contents without copying them.