26684 multipart related

This PR addresses the following:

- Push large attachments as MIME Multipart/Related parts
- Pull attachments as binary HTTP streams separately from document bodies
- Fix some of the interactions between the AttachmentManager and replications, ensuring correct handling of stub attachments revpos such that already known attachments are not needlessly transferred.

The PR also includes a Multipart/Related reader which is not currently used.

Some system properties are introduced:

``push_attachments_inline``: (default small)
* false = always push multipart
* small = push small attachments inline
* true = always push inline

Currently "small" attachments are defined as being < 65536 bytes.

``pull_attachments_inline``: (default false)
* false = always pull attachments as separate HTTP streams
* true = always pull attachments inline, as base64 data inlined in document body

It may be more efficient to pull attachments inline if it is known in advance that they will be small.

This is a problem but I'm not sure how to address it without a major re-factor. Inline (base64) attachments will get inserted as part of the transaction, but yes out-of-band ones won't.

The problem is that the BasicDatastore does the forceInsert and it can't know anything about the source database (Couch), so it doesn't know how to pull attachments back.

I guess we could start a tx before bulkInsert? Would the nested transactions do the right thing here?