Improve HTTP request-ending exception handling

`CEspHttpServer::processRequest` includes two try/catch blocks, one for reading the request and the other for processing the request. In both cases, the only exceptions translated into HTTP response content are IEspHttpException instances. For all other exceptions, request processing ends without responding to the requestor.

Recently, a security manager misconfiguration caused a string exception during user authentication. Requests submitted directly to the ESP in a browser timed out with no response. Requests submitted through a proxy server received "invalid response" errors without waiting for a timeout.

All exceptions that terminate request processing must send a response. The assumption for IEspHttpException is that the exception content is appropriate for the requestor's consumption. The assumption for all other exceptions is that the exception content, if any, is not appropriate for the requestor's consumption; these must simply acknowledge an error without conveying exception details.

For unknown exceptions, a generic "internal error" shall be reported. The request's global transaction ID, if available, shall be included in the message.

For IExceptions other than IEspHttpException, a generic "internal error" shall be reported along with a note that log files may contain additional information. The request's global transaction ID, if available, shall be included in the message.