Support logformat %codes in error page templates (#365)

Support logformat %codes in error page templates (#365)

... using `@Squid{%code}` syntax which allows Squid to distinguish newly
supported logformat %codes like `%http::<rm` from classic single-letter
error page %codes like `%M` (that are never enclosed in `@Squid{}`).

This improvement gives error pages access to more information about the
failed transaction and paves the way towards unifying the two partially
duplicated %code interfaces (and underlying code).

Some single-letter error page %codes have similar logformat %codes. For
example, error page `%i` will often be replaced with the same characters
as `@Squid{%>a}`. However, admins should not rely on expansion
equivalence because most codes may be rendered differently under some
conditions, and the two rendering algorithms are not kept in sync. For
example, error page `%i` does not account for log_uses_indirect_client.

Only a few letters remain unused by the error page %codes. Most
(possibly all) new codes should be added to the logformat instead,
within an appropriate error_page:: namespace if needed.

Side effects of updating error page parsing and assembly code include:

* Leave bad %codes in deny_info URLs instead of removing them. This
  helps in triage and is consistent with how bad %codes are already
  handled in error pages.

* Report bad deny_info %codes at startup and reconfiguration. Startup
  errors should eventually become fatal, just like logformat errors are.

* Report bad error page %codes at startup and reconfiguration (except
  for `%;` sequences found in all existing error pages templates).

* Fixed parsing of non-default error-details.txt that did not end with
  an empty line.

* Fixed unterminated c-string printing when reporting error-details.txt
  parsing problems.

* Upgraded MsgBody to use SBuf.

This is a Measurement Factory project.