[bug] RPC api forwards http headers incorrectly

[seeflood]

What happened:
When invoking RPC api using typescript sdk written in #262 ,the client got an error when parsing the response frame.

Error: 13 INTERNAL: Received RST_STREAM with code 1

What you expected to happen:
The typescript sdk invokes RPC api successfully

How to reproduce it (as minimally and precisely as possible):
Follow the README doc in #262

Anything else we need to know?:
There are two bugs:

1. We found that this bug was caused by directly forwarding the 'Content-Length' header to the client.
   If we modify Layotto's code and make it not to forward this field, the ut will invoke it successfully
   

2. Sometimes a different error occurs:

Error: 14 UNAVAILABLE: io: read/write on closed pipe

[wenxuwan]

I test golang client, don't have the error, so may be nodejs grpc framework have some different implementation， i will check it and give feedback

[seeflood]

Maybe we should add a metadata or header field in RPC API response?
There are two considerations:

1. Make the protocal transparent. Users do not need to pay attention to the real protocol
2. The rpc api not only supports the transfer to http, but also supports transfer to other rpc protocols; if the headers of other protocols are passed back transparently, they may also encounter field conflicts;
   So adding a field is a solution