Improve ErrorState debugging

[rousskov]

In triage, it is often useful to know that ErrorState was created when
it was created rather than waiting for errorAppendEntry() or errorSend()
debugging, especially if those error handling stages are not reached.

Also report HTTP status code of the error response (when available).

[rousskov]

This PR was triggered by #1767 (comment)

Sample output:

| 4,3| errorpage.cc(712) ErrorState: ERR_CANNOT_FORWARD/http_status=502
| 17,3| FwdState.cc(461) fail: ERR_CANNOT_FORWARD/http_status=502; was: [nil]
| 4,4| errorpage.cc(739) errorAppendEntry: storing ERR_CANNOT_FORWARD/http_status=502 in e:=p2XIHWV/0x55c661abe320*4
| 4,2| errorpage.cc(1411) buildBody: No existing error page language negotiated for ERR_CANNOT_FORWARD/http_status=502. Using default error file.

The comments in this review annotate the diff. They do not request any code changes.

[yadij]

Just some minor polish.

[yadij]

Please use "comma SP" separator here, as is typical for lists of details about something.

Suggested change

	os << "/http_status=" << err.httpStatus;
	os << ", http_status=" << err.httpStatus;

[rousskov]

The formatting here follows %err_code/%err_detail formatting model that many admins use (and I recommend for human-read logs).

IMO, the information printed here is not really a list; the printed items do not belong to the same "level" where enumeration would be natural. Instead, it is a primary ERR_FOO entry with optional/secondary detailing. Rendering this information as a list and using whitespace (without surrounding the whole things with curly braces) will make some likely debugging use cases (that contain commas and spaces for higher-level reasons) more difficult to interpret.

Please keep this summary output looking as a single "field" or "token".

[yadij]

Admin reading cache.log will be expecting to see the same syntax found in all the surrounding lines. Which is key=value separated by comma.

[rousskov]

Admin reading cache.log will be expecting to see the same syntax found in all the surrounding lines. Which is key=value separated by comma.

In cache.log context, we do not have a standard format for this kind of information, and I do not think we should start defining one here. There are already many ways similar information is logged, including lists, structures, compact tokens, and even multiline records. Folks seeing these values are unlikely to misunderstand them because of this particular format choice (a format that fits this data better than a list would and that will look familiar to many admins that log %err_code/%err_detail).