If the application provides a `gcs::Crc32ChecksumValue()` or
`gcs::MD5HashValue()` to `InsertObject()` we should use those values to
create the metadata portion of the upload. Otherwise we are losing an
opportunity to validate the data integrity during the upload.

I discovered this while refactoring and restructuring the integration
tests for CRC32C checksums and MD5 hashes. Apologies for the massive
changes in the tests for what amounts to a small fix.

The tests now have 3 portions, one for `InsertObject()`, one for
`WriteObject()` and one for `ReadObject()`. Unlike before, the code for
XML and JSON tests is shared, though this required some changes in the
emulator to make it easier to detect what hash fields (if any) were
including in the upload.

For `InsertObject()` and `WriteObject()` we test 5 scenarios: (1) using
the default settings, which are enabled for CRC32C, and disabled for
MD5, (2) explicitly disabling the hash, (3) explicitly enabling the
hash, (4) setting the hash to the correct value, and (5) setting the
hash to the incorrect value.

For `WriteObject()` we also test detecting an invalid hash, both in the
case where the library computes the hash and the case where the
application provides it.

For `ReadObject()` it is simpler, because we cannot provide expected
hashes. So we only test the cases where the hash check is in its default
setting (enabled for CRC32, disabled for MD5) and that hash mistmatches
are detected when the hash is enabled.