deps: Update to the experimental msgpack 2.0 branch

Using msgpack 2.0 will let nvim be more compatible with msgpack libraries for
other platforms.

This also replaces "raw" references by "bin" which is the new name for msgpack
binary data type
Temporarily switch neovim/deps url
Temporarily switch python-client branches
map/msgpack-rpc: Declare/define maps rpc method handlers

The new map type uses `String` instances as keys to avoid unnecessary copying to
zero-terminated buffers.
msgpack-rpc: Refactor initializer and dispatcher

Use Map(String, rpc_method_handler_fn) for storing/retrieving rpc method
handlers in msgpack_rpc_init and msgpack_rpc_dispatch.

Also refactor serialization/validation functions in the
msgpack_rpc.c/msgpack_rpc_helpers.c modules to accept the new STR and BIN types.
msgpack-rpc: Move handle_missing_method to msgpack_rpc.c

Since that function is not automatically generated, it's best to place it in a
normal C module
msgpack-rpc: Refactor API metadata discovery method

A new method is now exposed via msgpack-rpc: "get_api_metadata". This method has
the same job as the old method '0', it returns an object with API metadata for
use by generators.

There's one difference in the return value though: instead of returning a
string containing another serialized msgpack document, the metadata object is
returned directly(a separate deserialization step by clients is not required).
msgpack-rpc: Remove support for integer ids in methods

There's no need to have integer and string ids, and since we now fully support
msgpack-RPC, support for integer ids was removed.
memory: Use i18n messages for memory-related errors
msgpack-rpc: Remove the `msgpack_rpc_unpack` function

The `msgpack_rpc_unpack` function was created to work around a deficiency in the
msgpack unpack API, which did not let the caller know if parsing failed due to
needing more data or to invalid input. The deficiency does not exist in the
latest version of `msgpack_unpacker_next`, so it can safely be removed.
api/msgpack-rpc: Remove specialized array types

Specialized array types(BufferArray, WindowArray, etc) were added to the API for
two main reasons:

- msgpack used to lack a way of serializing appliaction-specific types and there
  was no obvious way of making an API function accept/return arrays of custom
  objects such as buffers(which are represented as integers, so clients didn't
  have a way to distinguish from normal numbers)
- Let clients in statically-typed languages that support generics have a better
  typed API

With msgpack 2.0 EXT type the first item is no longer a factor and this commit
starts by removing the specialized array types. The second item will be
addressed in the future by making the API metadata return extra useful
information for statically-typed languages.
api/msgpack-rpc: Parse type information from api/private/defs.h

Enhance msgpack-gen.lua to extract custom api type codes from the ObjectType
enum in api/private/defs.h. The type information is made available from the api
metadata and clients can use to correctly serialize/deserialize these types
using msgpack EXT type.
api/msgpack-rpc: Use EXT type to serialize Buffer/Window/Tabpage