Support gRPC APIs about hypersdk

[richardpringle]

We should in theory be able to support both json-rpc and grpc simultaneously.

@joshua-kim, when you were talking about getting rid of the controller, I was reminded of a pattern I had used in the past. It was for a wallet, but still.

We had multiple apis, one was effectively REST, then we added a grpc-api. We didn't want to stop supporting the REST API because it was difficult for that client to change their code (for reasons). Any new clients would have to use grpc (no more swagger docs or anything that we had to manually keep in sync). The "controller" was used to implement all the business logic to respond to the API request. Then we just had some glue code to take in the HTTP-params (validation, etc), and call the controller. Grpc was the same (but easier). We re-used the same validation code.

All that's to say, it would be best if the RPC layer was as decoupled as possible, such that HyperVM implementers could modify the API surface and protocols as they see fit.

Maybe that's not opinionated enough. though?

It's also possible to say that if you want a different kind of API, just run a sidecar that does the translation.