[RFC] Update to the experimental msgpack 2.0 branch and other msgpack-rpc improvements

Using msgpack 2.0 changes that will impact us:

- `RAW` was renamed to `STR`, which is a byte array containing only utf-8 sequences. This is the reason why some msgpack libraries(eg: node.js) fail to deserialize the API metadata
- `BIN` was added to represent arbitrary byte arrays. Since this is a new type code, only clients supporting msgpack 2.0 can understand it.
- `EXT` was added to support custom API-specific types. This is great because we can use type codes for automatic client deserialization of Window, Buffer, etc(no need to perform the metadata-signature-name-checking hack currently done in the python client). In particular, I intend to remove typed arrays(BufferArray,WindowArray) which only exist as hint mechanism for python-client. We can support typed arrays in static languages by adding more information to the API metadata(which is cleaner since C doesn't support generics)

The msgpack-c branch supporting 2.0 is still beta, but I think it's best we start using it for two reasons:

- Lots of libraries already support msgpack 2.0
- Neovim is still in alpha state, so it's a good opportunity to help @redboltz test the branch before it's merged into mainline

Here's an overview of things that will be done in this PR:

- Use the improved `msgpack_unpacker_next` function
- Remove integer method ids(We only need one way of doing RPC)
- Make the method '0' callable through the "get_api_metadata"
- Use msgpack EXT to serialize special integer types such as Buffer, Window, etc
- Remove typed arrays. With msgpack EXT we only need a generic array



> Is capacity ever used and if it is should it not be initialized with one of the init macros? (See also Dictionary)

:+1: