Add support for system messages

This change provides support for cowboy process handling requests to
handle system messages from the `sys` module.

When receving a message of the form `{system, From, Msg}` a
middleware (or sub_protocol) should return the following to handle the
message:

`{system, From, Msg, Module, Req, State}`

The system message will be handled for the middleware (or sub_protocol)
using the `sys` module. Control is returned via the `cowboy_sys`
callbacks:

* `sys_continue(Req, State)` - called when the middleware (or
sub_protocol) should continue processing as before.
* `sys_terminate(Reason, Req, State)` - called when the middleware (or
sub_protocol) should do any cleanup and then exit with reason `Reason`.

`cowboy_loop` and `cowboy_websocket` both handle system messages,
allowing live debugging of long running requests.

If a handler does not upgrade to a sub_protocol that handles system
messages, a system message received by a cowboy request process may
be handled after the current requested has finished processing but
before the next request.

Calling `sys:get_state/1,2` on a cowboy request process will return:

`{cowboy_protocol, undefined, State}`

Or:

`{Module, Req, State}`

The `Module` will be a middleware (or sub_protocol), `Req` the current
request object and `State` the state of the current module. Note the
special case of `cowboy_protocol` where `Req` is `undefined` as there is
currently no request object because the process is between requests.
This will occur when a middleware (or sub_protocol) does not handle
system messages.

The replace fun used in `sys:replace_state/2,3` on a cowboy request
process should accept, and return, a state of the form returned by
`sys:get_state/1,2`.

Calling `sys:get_status/1,2` on a cowboy request process will yield
slightly more information, and the request object will be formatted
using `cowboy_req:to_list/1`.

Note that all `sys` module functions will work on cowboy processes, but
calling `sys:change_code/4,5` will not change the state of a process.
Also cowboy processes do not generate any `sys` debug events, so some
other functions are of limited use.

A requirement of supporting the `sys` module is using `proc_lib`. This
has the following side effects:
* A `crash_report` is sent to the error logger on abnormal exit.
* The emulator will nolonger send an event to the error logger when an
exception is not caught.
* Uncaught errors will nolonger have a stacktrace in their exit reason.
This made it difficult to know the class of the exception causing the
exception and so the class of an exception has been added to all exit
reasons when a handler raises an exception.