eval: Add eval_call_provider/eval_has_provider functions

These use autoloaded vimscript to replace the provider_call/provider_has
functions, moving the implementation of providers to pure vimscript(we lose
nothing since vimscript can also call msgpack-rpc functions).

When calling the rpcrequest function from a provider, temporarily switch to the
caller scope. This is required for compatibility with legacy plugins, because
they may depend on scope information that changes when "leaving" the C stack to
enter the vimscript stack.
eval/ex_cmds2/ops: Implement providers with eval_call_provider

Replace references to provider_call/provider_has with the new functions
eval_call_provider/eval_has_provider.
Remove os/provider.{c,h} and all of its references
channel: Remove invalid free_channel call

When a job fails to start, it will already call the exit_cb which takes care of
freeing the channel.
channel: Improve error reporting for invalid responses
runtime: Add vimscript support for external plugins

External plugins(a.k.a msgpack-rpc plugins) are now supported through a
library of vimscript functions that deals with:

- Associating plugin host names(eg: python, ruby, go) with channel ids
- Registration of external plugins
- Definition of commands, autocmds and functions lazily implemented over
  msgpack-rpc
runtime: Reimplement python/clipboard providers in vimscript

Clipboard is implemented with platform-specific shell commands, and python is
implemented with the external plugin facility (rpc#* functions). The
script_host.py file(legacy python-vim emulation plugin) was moved/adapted from
the python client repository.
runtime: Remove 'python_setup.vim'
test: Add tests for the rpc#define#* functions
test: Add tests for the python provider

These tests were adapted from the python-client repository
docs: Update to the latest changes in the plugin infrastructure
Merge PR #1454 'Refactor plugin system'
Fix warnings: tag.c: test_for_static()/get_tags(): Various (2): FP.

Problems   : Assigned value is garbage or undefined @ 2191.
             Uninitialized argument value @ 2796.
Diagnostic : False positives.
Rationale  : Both problems share the same cause.
             Error happens in get_tags(), if parse_match() fails because
             of parse_tag_line() failing before. Then, `tp` is not
             correctly initialized and subsequent code accesses garbage
             values.
             This is not really possible, as parse_tag_line() should not
             fail after find_tags() has been successful.
             That is because find_tags() already does tag line parsing,
             using parse_tag_line() itself for it (or a quicker
             alternative that should produce same result). That's why
             return value of parse_match() is ignored, and subsequent
             code assumes it is successful.
Resolution : Assert parse_match() always successful.
Fix warnings: tag.c: jumpto_tag(): Np dereference: MI.

Problem    : Dereference of null pointer @ 2399.
Diagnostic : Multithreading issue.
Rationale  : Error can only occur if global `g_do_tagpreview` changes
             while the function is executing.
Resolution : Use local copy of global var.
Fix warnings: tag.c: get_tags(): Uninitialized arg: RI.

Problem    : Uninitialized argument value @ 2798.
Diagnostic : Real issue.
Rationale  : Tags doesn't have to have a kind. When they have one, both
             `tp.tagkind` and `tp.tagkind_end` are nonnull. But when
             they don't, `tp.tagkind` will we null (but defined), while
             `tp.tagkind_end` will be undefined.
             Therefore, reported invocation is indeed using a garbage
             value for a tag with no kind.
             Problem doesn't have consequences because `add_tag_field()`
             doesn't use `end` param if `start` param is null.
Resolution : Don't use `tp.tagkind_end` if `tp.tagkind` is null.
Fix warnings: window.c: win_rotate(): Np dereference: FP.

Problem    : Dereference of null pointer @ 1268.
Diagnostic : False positive.
Rationale  : Suggested error path implies current window's frame to be
             the only child of its parent, which is ruled out by
             `if (firstwin == lastwin) {` check at the beginning.
Resolution : Assert another child remains after removing current frame.
             Strictly, assert is only needed in false branch of
             conditional, but we add it the same in the true branch to
             reduce reader surprise.
             Several forms of a single assert after
             `if (firstwin == lastwin) {` were tried, but analyzer
             cannot follow implications that way.
Fix warnings: window.c: winframe_remove(): Np dereference: FP.

Problem    : Dereference of null pointer @ 2196.
Diagnostic : False positive.
Rationale  : Suggested error path implies `frp->child == NULL` while
             being under condition `frp2->fr_layout == frp->fr_layout`,
             which is impossible:
             - If frp2 is frp's parent, then frp2's layout is FR_COL or
               FR_ROW;
             - if frp->child is NULL, the frp's layout is FR_LEAF.
             - Therefore, they can't be equal.
Resolution : Assert frp->child not null.
Fix warnings: window.c: win_drag_vsep_line(): Np dereference: FP.

Problem    : Dereference of null pointer @ 4512.
Diagnostic : False positive.
Rationale  : Suggested error path implies `fr == NULL` after 4504.
             That's not possible, because:
             - curfr and curfr->next must be both nonnull, as we are
               dragging the divider between the two.
             - after conditional, fr is one of those two (the one that
               grows).
Resolution : Assert fr.
Fix warnings: window.c: tabline_height(): Np dereference: FP.

Problem    : Dereference of null pointer @ 4978.
Diagnostic : False positive.
Rationale  : tabline_height() shouldn't be called when a tab doesn't
             exist yet (this is, before initialization).
Resolution : Assert function precondition.
Fix warnings: eval.c: set_var_lval(): Np dereference: FP.

Problem    : Dereference of null pointer @ 2273.
Diagnostic : False positive.
Rationale  : Suggested error would happen when assigning an rvalue with
             more items than the lvalue. Then we would enter conditional
             at:
             ```
             if (lp->ll_li->li_next == NULL) {
               /* Need to add an empty item. */
               list_append_number(lp->ll_list, 0);
             }
             lp->ll_li = lp->ll_li->li_next;
             ```
             Analyzer thinks the value assigned to lp->ll_li is still
             NULL and is hit on the next iteration.
Resolution : Assert lp->ll_li->li_next is not null anymore after
             list_append_number().