rstream: Initialize 'rstream' field in RBuffer class

This field is used in a conditional jump, so this initialization is fixing a
bug.
rstream: Add rbuffer_read_ptr/rbuffer_write_ptr functions

rbuffer_data was renamed to rbuffer_read_ptr, and it represents the next read
position in a RBuffer instance. Similarly, rbuffer_write_ptr was added to
represent the next write position.

Also, rbuffer_data was being used for writing(in alloc_cb), replace that by
rbuffer_write_ptr.
Merge PR #1306 'RBuffer fixes'
Improve YCM contrib: Fix 'no newline at end of file' issue.

Problem:  YCM was reporting a much disturbing warning about a missing
          newline at the end of some files. This was odd, as the
          newlines were there and the warning only was shown for some
          files, not for all of them.
Cause:    After discussing this issue with @Valloric (see
          https://github.com/Valloric/YouCompleteMe/issues/950), it
          turned out that not YCM, but libclang is responsible for it.
          This is, same compilation flags that produce no warnings with
          clang-the-binary on the command line, do produce them with
          libclang-the-library when used by YCM.
Solution: Add an extra flag (-Wno_newline_eof) to those extracted from
          configuration database before passing them to YCM.
Improve YCM contrib: Improve documentation.
Merge PR #1310 'Improve YCM contrib.'
CMake: Set execute permissions during installation.
version: remove "Running in Vi compatible mode" message #1309
Fix sign column redraw

Fixed a bug introduced in SHA:aa66f2487edde49b9a5ba10cd70d706d06a94e25,
due to a misapplied patch. buf_del_sign should redraw the window if the
sign deleted was the last one in the buffer.
Also moved the curwin verification to the correct function.
Merge pull request #1311 from GokuITA/issue1295

Fixed sign column redraw
Merge pull request #1313 from fwalch/runtime-programs

CMake: Set execute permissions during installation.
A few fixes for YCM contrib docs and code
Merge pull request #1319 '[RFC] A few fixes for YCM contrib docs and code'
msgpack-rpc: Create subdirectory for msgpack-rpc modules

Create the msgpack_rpc subdirectory and move all modules that deal with
msgpack-rpc to it. Also merge msgpack_rpc.c into msgpack_rpc/helpers.c
channel: Simplify resource management

- Remove unused rpc_call_level field
- Add `returned` field to ChannelCallFrame. This is set when the call returns
  and is the only condition checked by `channel_send_call`.
- Add job_exit callback for properly closing channels created from job(the
  job_exit callback is only called after all read callbacks, so it's the only
  safe place to free the channel).
event: Remove EventType enum and pass a callback to `event_push`

This approach is more flexible because we don't need to support a fixed set of
"event types", any module can push events to be handled in main loop by simply
passing a callback to the Event structure.
event: Remove automatic event deferall

This is how asynchronous events are currently handled by Nvim:

- Libuv event loop is entered when Nvim blocks for user input(os_inchar is
  called)
- Any event delivered by libuv that is not user input is queued for processing
- The `K_EVENT` special key code is returned by os_inchar
- `K_EVENT` is returned to a loop that is reading keys for the current Nvim
  mode, which will be handled by calling event_process()

This approach has the advantage of integrating nicely with the current
codebase, eg: vimscript code can be executed asynchronously with little
surprises(Its the same as if the user typed a key).

The problem with using keys to represent any event is that it also interferes with
operators, and not every event needs or should do that. For example, consider
this scenario:

- A msgpack-rpc client calls vim_feedkeys("d")
- Nvim processes K_EVENT, pushing "d" to the input queue
- Nvim processes "d", entering operator-pending mode to wait for a motion
- The client calls vim_feedkeys("w"), expecting Nvim to delete a word
- Nvim processes K_EVENT, breaking out of operator-pending and pushing "w"
- Nvim processes "w", moving a word

This commit fixes the above problem by removing all automatic calls to
`event_push`(which is what generates K_EVENT input). Right now this also breaks
redrawing initiated by asynchronous events(and possibly other stuff too, Nvim is
a complex state machine and we can't simply run vimscript code anywhere).

In future commits the calls to `event_push` will be inserted only where it's
absolutely necessary to run code in "key reading loops", such as when executing
vimscript code or mutating editor data structures in ways that currently can
only be done by the user.
event: Extract event_poll loops to `event_poll_until` macro

A pattern that is becoming common across the project is to poll for events until
a certain condition is true, optionally passing a timeout. To address this
scenario, the event_poll_until macro was created and the job/channel/input
modules were refactored to use it on their blocking functions.
eval: Defer execution of JobActivity autocommands

JobActivity autocommands run vimscript and must be executed on Nvim main loop.
Since the previous commit removed automatic calls to `event_push` on RStream/Job
callbacks, this adds it back, but in eval.c where job control is implemented.
msgpack-rpc: Allow selective deferral API calls

Since all API functions now run immediately after a msgpack-rpc request is
parsed by libuv callbacks, a mechanism was added to override this behavior and
allow certain functions to run in Nvim main loop.

The mechanism is simple: Any API function tagged with the FUNC_ATTR_DEFERRED (a
"dummy" attribute only used by msgpack-gen.lua) will be called when Nvim main
loop receives a K_EVENT key.

To implement this mechanism it was necessary some restructuration on the
msgpack-rpc modules, especially in the msgpack-gen.lua script.