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'
Fix #838: build with "USE_BUNDLED=OFF" fails to find dependencies

Stop forcing some platform setting that are really intended to be used
for Travis CI.  Under other systems, like Arch Linux, it prevents
dependencies from being correctly located.