Escape CR and LF in WARC metadata records and resource Content-Type (#2109)

* Escape CR and LF in WARC metadata records and resource Content-Type

MetadataRecordFormat.format() wrote one line per metadata value into the
application/warc-fields payload without checking for CR or LF. A value
containing CR LF (e.g. feed.description set by FeedParserBolt, or values
of parse.* filters such as the XPath, LDJson and Tika filters) therefore
became additional field lines that look exactly like fields written by
the crawler - for example a fabricated hopsFromSeed or via. Framing
stayed valid because Content-Length is computed from the finished
payload, so WARC readers had no way to detect the injected fields.

- replace CR and LF by spaces in metadata values written into the
  warc-fields payload, and drop metadata keys that are not valid WARC
  field names (printable ASCII without colon, RFC 5322 section 2.2)
- sanitise the server-supplied Content-Type used for resource records in
  WARCRecordFormat.format(), which was appended verbatim into the WARC
  header block
- log MetadataRecordFormat messages under MetadataRecordFormat instead
  of WARCRequestRecordFormat

Fixes #2105

* Validate warc.metadata.keys once on instantiation

The configured metadata keys are fixed topology configuration: check
them for valid WARC field names in the constructor and drop invalid
keys with a single warning, instead of repeating the check and warning
for every record written. Suggested in review.

* Make null check in isValidWarcFieldName explicit

The conjunction already returned false for a null name through
short-circuit evaluation, but the intent was easy to miss. Return false
explicitly and cover the field name and value sanitisation helpers with
unit tests. Suggested in review.