update style guide URL
event: Bail out of event_poll when any event is processed

The loop condition was set to only exit when user input is processed, but we
must exit on any event to properly notify `event_poll` callers
event: Decouple user input checks from `event_poll`

This was done to generalize the usage of `event_poll`, which will now return
`true` only if a event has been processed/deferred before the timeout(if not
-1).

To do that, the `input_ready` calls have been extracted to the input.c
module(the `event_poll` call has been surrounded by `input_ready` calls,
resulting in the same behavior).

The `input_start`/`input_stop` calls still present in `event_poll` are
temporary: When the API becomes the only way to read user input, it will no
longer be necessary to start/stop the input stream.
job: Fix vimscript wrapper by returning when an invalid id is passed
wstream: Refactor buffer memory management

- Extract code to release WBuffer instances into `release_wbuffer`
- Fix memory leak when wstream_write returns false
wstream: Use a default value of 10mb for `maxmem` when 0 is passed
wstream: Make wstream_write consider the return value from uv_write
job: Add a `maxmem` parameter to job_start

The value is forwarded to it's own WStream instance
channel: Extract 'channel_write' function
channel: Extract function for sending errors that are not responses
channel/msgpack_rpc: Refactor msgpack_rpc_notification/serialize_event

- Generalize some argument names(event type -> event name,
                                 event data -> event arg)
- Rename serialize_event to serialize_message
- Rename msgpack_rpc_notification to msgpack_rpc_message
- Extract the message type out of msgpack_rpc_message
- Add 'id' parameter to msgpack_rpc_message/serialize_message to create messages
  that are not notifications
channel: Implement the  'channel_send_call' function

This function is used to send RPC calls to clients. In contrast to
`channel_send_event`, this function will block until the client sends a
response(But it will continue processing requests from that client).

The RPC call stack has a maximum depth of 20.
channel/msgpack_rpc: Refactor to better split functions across modules

Move validation/conversion functions and to msgpack_rpc_helpers to separate
those from the functions that are used from the channel module
channel/msgpack_rpc: Refactor API dispatching

This is how API dispatching worked before this commit:

- The generated `msgpack_rpc_dispatch` function receives a the `msgpack_packer`
  argument.
- The response is incrementally built while validating/calling the API.
- Return values/errors are also packed into the `msgpack_packer` while the
  final response is being calculated.

Now the `msgpack_packer` argument is no longer provided, and the
`msgpack_rpc_dispatch` function returns `Object`/`Error` values to
`msgpack_rpc_call`, which will use those values to build the response in a
single pass.

This was done because the new `channel_send_call` function created the
possibility of having recursive API invocations, and this wasn't possible when
sharing a single `msgpack_sbuffer` across call frames(it was shared implicitly
through the `msgpack_packer` instance).

Since we only start to build the response when the necessary information has
been computed, it's now safe to share a single `msgpack_sbuffer` instance
across all channels and API invocations.

Some other changes also had to be performed:

- Handling of the metadata discover was moved to `msgpack_rpc_call`
- Expose more types as subtypes of `Object`, this was required to forward the
  return value from `msgpack_rpc_dispatch` to `msgpack_rpc_call`
- Added more helper macros for casting API types to `Object`
  any
Merge pull request #872 'Add support for client-side RPC'