[RFC] Replace current ffi with pybind11

## Proposal
pybind11 is a lightweight header-only library that exposes C++ types in Python and vice versa, mainly to create Python bindings of existing C++ code.

Many projects now use this, including:

- PyTorch
- PyTorch migrated from cffi to pybind11 in 1.0 release
- Tensorflow
- Tensorflow started migrating from swig to pybind11 recently, and plan to finish this by the end of 2020 Q1 ([link](https://github.com/tensorflow/community/blob/master/rfcs/20190208-pybind11.md))
- Others
- nvidia/dali
- rapidai
- Actually it's hard to find a project not using pybind11

## Pros of pybind11 over current ffi:

- Bigger community
- pybind11 is widely used. Easier to find solution if we meet problems.
- Better composibility with other framework
- Since tf and pytorch is/will use pybind11, this would make it easier to interact with them
- Everything is compiled
- The functions are compiled to be called directly. Current ffi needs extra python calls with ctypes to dispatch/convert to pointers. Potentially it might could bring us better performance (not sure).
- Better container support
- pybind11's `py::list` has the same API as Python, which is powerful than current `List`
- External developer friendly
- Pybind11 has detailed docs, and more friendly interfaces. This would make external developer easier to contribute.
- Better graduanlity control
- Current ctypes function release and acquire GIL for every function call. This would lead to performance issue when calling a light function massively, if we don't need to release GIL. pybind11 can release/acquire GIL on-demand in C++.

## Cons of pybind11 over current ffi:

- Needs extra work to change ffi
- Compilation time may increase, and depends on Python API and OS
- pybind11 compiles codes to be called directly, which depends on specific Python version.
Current ffi does not depend on Python API and OS, because ctypes handles those things
- Need to compile for different python version separately when release

Generally speaking, pybind11 is easier to use, and possibly could bring us better performance, due to GIL issue and bypass multiple python calls comparing to current implementations.