Refactor body-related conversion logic into a new BodyConverter.

* A minimum-viable-product for additional changes, without altering existing
  customer-facing behavior.
* This change itself should offer no functional change (i.e., no test data
  was changed).
* The longer intent is to simplify (via centralization) the handling of
  different HTTP bodies (gzipped or not, text or not, inline storage or not).
* This change provides staging for a change to add configurability (via a
  Configuration) to BodyConverter, in the form of three conversion steps:
  * Pre-processing: handle Content-Encoding and Transport-Encodings like gzip,
    deflate.
  * Conversion: Today, we attempt to detect and convert "text"-like Content-Types
    to UTF8 strings, enhancing tape readability above binary-like
    Content-Types.
  * Post-procesing: external file storage (via FileResolver).
* Message interface: getBodyAsBinary() is no longer expected
  to decode/convert the raw HTTP body. Hopefully cleans up some code -- previously
  Messages were expected to provide conversion without being tooled to perform
  them (decoders).
  * Future change should remove other forms of access to the Body.
  * RecordedMessage provides access to the 'decoded' body (i.e., String).