provider: New module used to expose extension points for core services

Introducing the concept of providers: co-processes that talk with the editor
through the remote API and provide implementation for one or more core
services.

The `provider_register` function and it's API wrapper can be used by channels
that want to self-register as a service provider.

Some old builtin vim features will be re-implemented as providers. The
`provider_feature_available` function is used to check if a provider
implementing a certain feature is available(It will be called by the `has`
vimscript function to check for features in a vim-compatible way)

This implements the provider module without exposing any extension points, which
will be done in future commits.
provider: Add support functions for calling external interpreters

This uses the provider module infrastructure to implement common code for
vimscript commands/functions that need to communicate with external
interpreters, eg: pydo, rubydo, pyfile, rubyfile, etc.
provider: Add support for python commands/functions

This uses the provider/scripting infrastructure to reintroduce python support
through the msgpack-rpc API.

A new 'initpython' option was added, and it must be set to a command that will
bootstrap the python provider the first time it's needed.
provider: Add support for clipboard registers.

This reimplements the '+'/'*' clipboard registers(both are aliases to the same
register, no dedicated storage for the X11 selection) on top of the provider
infrastructure.

This adds two new options:

- 'unnamedclip': has the same effect of setting 'clipboard' to
  'unnamed/unnamedplus' in vim
- 'initclipboard': command that bootstraps a cliboard provider the first time
  it's needed.

The 'clipboard' option was not reused because all values(except 'unnamedplus')
seem to be useless for Neovim, and the code to parse the option was relatively
big. The option remains for vim compatibility but it's silently ignored.
api: make buffer_{get,set}_slice automatically assume `include_end`

This is for compatibility with python-vim interface: When passing an end index
with a value higher than the last index, assume the `include_end` flag
getchar: fix infinite loop due to pending events

The `inchar` function could enter an infinite loop if there are events pending
to be processed when an interrupt is received.
api/events/msgpack: Insert log statements to improve debugging

Also changed the default log level to INFO so developers won't end up with big
log files without asking explicitly(DLOG statements were placed in really "hot"
code)
events: Refactor how event deferral is handled

- Remove all *_set_defer methods and the 'defer' flag from rstream/jobs
- Added {signal,rstream,job}_event_source functions. Each return a pointer that
  represent the event source for the object in question(For signals, a static
  pointer is returned)
- Added a 'source' field to the Event struct, which is set to the appropriate
  value by the code that created the event.
- Added a 'sources' parameter to `event_poll`. It should point to a
  NULL-terminated array of event sources that will be used to decide which
  events should be processed immediately
- Added a 'source_override' parameter to `rstream_new`. This was required to use
  jobs as event sources of RStream instances(When "focusing" on a job, for
  example).
- Extracted `process_from` static function from `event_process`.
- Remove 'defer' parameter from `event_process`, which now operates only on
  deferred events.
- Refactor `channel_send_call` to use the new lock mechanism

What changed in a single sentence: Code that calls `event_poll` have to specify
which event sources should NOT be deferred. This change was necessary for a
number of reasons:

- To fix a bug where due to race conditions, a client request
  could end in the deferred queue in the middle of a `channel_send_call`
  invocation, resulting in a deadlock since the client process would never
  receive a response, and channel_send_call would never return because
  the client would still be waiting for the response.
- To handle "event locking" correctly in recursive `channel_send_call`
  invocations when the frames are waiting for responses from different
  clients. Not much of an issue now since there's only a python client, but
  could break things later.
- To simplify the process of implementing synchronous functions that depend on
  asynchronous events.