Add basic support for system messages

This change provides support for Cowboy request processes 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:

`{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 to `Module` 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 either `cowboy_protocol` or `cowboy_spdy_request`,
depending whether the process is handling HTTP(S) or SPDY requests. 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.

`State` is the internal state of the current module (e.g.
`cowboy_protocol`), rather than the current middleware or subprotocol.
The internal state formats of `cowboy_protocol` and
`cowboy_spdy_request` are not documented. However the module and state
of the current middleware will be included in somewhere in state.

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.

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
error or throw is not caught.
Add support for sys:get_state/{1,2} & sys:replace_state/{2,3}

This change provides support for Cowboy request processes to
handle the get and replace state system messages for live debugging.

These system messages are handled using new `cowboy_sys` callbacks:

* `sys_get_state(Req, State)` - called when the middleware (or sub
protocol) should return its state (or its handler's state).
* `sys_replace_state(Replace, Req, State)` - called when the middleware
(or sub protocol) should replace its  state (or its handler's state).

`sys_get_state/2` has two possible return values:

* `{ok, Req, State}` will return `{?MODULE, Req, State}` from
`sys:get_state/{1,2}`.
* `{Module, Req, ModuleState}` will return `{Module, Req, ModuleState}`
* from `sys:get_state/{1,2}`.

A middleware will usually return `{ok, Req, State}`. However a sub
protocol with a callback handler may wish to return information about
its handler, rather than itself. In this case it would return
`{Handler, Req, HandlerState}`. Both `cowboy_loop` and
`cowboy_websocket` do this.

Note that `sys_get_state/2` is idempotent so the `Req` (and state) can
not be changed.

The `Replace` (first) argument in `sys_replace_state/3` is as 1-arity
anonymous function used to replace the state term returned by
`sys:get_state/{1,2}`. For example: `Replace({?MODULE, Req, State})`.

`sys_replace_state/3` has two possible return values:

* `{ok, Req, State}` will return `{?MODULE, Req, State}` from
`sys:replace_state/{2,3}` and change the request object to `Req` and the
middleware's state to `State`.
* `{Module, Req, ModuleState, State}` will return
`{Module, Req, ModuleState}` from `sys:replace_state/{2,3}` and change
the request object to `Req` and the middleware's state to `State`.

A middleware will usually return `{ok, Req, State}`. However a sub
protocol with a callback handler may wish to replace the state of its
handler, rather than itself. In this case it would return
`{Handler, Req, HandlerState, State}`, where `State` is the full `State`
of the sub protocol. Both `cowboy_loop` and `cowboy_websocket` will
replace the state of their handler.

To prevent confusion a middleware or sub protocol MUST be sure to apply
the expose the same module and state to `sys_get_state/2` and
`sys_replace_state/3`.

Note that as before a system message might be handled between requests
by `cowboy_protocol`. As previously in this case the `Req` will be the
atom `undefined`.