Redesign our grpc interface

[MichaelScofield]

Our grpc interface needs a thorough redesign, some things are not good now. For example, the name "object" and "expr" used through out our grpc implementation are unclear in themselves; conventions between grpc objects and other protocol results and requests are tedious and cumbersome; hard to use grpc cli tools to debug; etc.

Some related issues are:

• [x] #544
• [ ] #480
• [ ] #381

[sunng87]

As we merged frontend and datanode into standalone mode, it's time to consider a new user-facing grpc api in separate of the current internal one. (The internal one needs to evolve too) The main user-facing api can just provide a simple sql interface to match current http/db apis. We still need grpc as a first-class transport because it has good support for streaming response, which is going to be one of our important features in future.