字符串配置项支持传递参数

像命名服务，负载均衡，协议选择除了指定名称以外，还需要一些配置项。比如一致性哈希中可能要指定不同的hash算法或replica个数，比如http/h2协议中要指定content-type。

目前的解决方法要么是增加一个不同的入口，比如c_md5和c_murmurhash分别是使用md5和murmurhash作为hash算法的一致性哈希负载均衡算法，但这种方法能传递的信息有限，还会面临组合爆炸的问题。要么是通过全局gflag控制一个进程中所有相关的行为，这种方法粒度比较粗，有时是不合适的。

目前需要解决这个问题的动机主要在于http/h2协议中出现的各种变种问题：
* http有三个主要变种：body由用户指定, body是pb二进制, body是由pb转成的json。
* h2/h2c也有类似的三种情况
* grpc是基于h2/h2c的协议，但要特殊处理headers/body，所以也要区分对待。grpc内部还要继续区分pb和json。

在最原始的实现下，只有http和h2c两个协议。区分上述不同的body都要设置content-type。但这在实用中会有很多麻烦，比如content-type要通过专门的参数传递。content-type也比较长，容易搞错。另外一个现有程序一定要修改代码（增加content-type参数，并set到controller里）才能跑http/h2协议上的一些变种，比如http的content-type不设的话默认就是application/json，要跑成application/proto的话就得改代码，增加额外的set_content_type代码。

协议中能直接夹带参数的话，一些事情会便利和直观一些，比如http带pb就写成"http:proto"，grpc写成"h2c:grpc"，"h2c:grpc+proto", "h2c:grpc+json"等等。协议名和参数用冒号分隔，参数由对应协议代码自行理解。

应该注意到协议、命名服务、负载均衡对传入参数的要求是不同的，后两者能传入的信息渠道有限，如果没有参数，就只有全局gflags了，所以它们很可能需要传入较多参数，不同参数用不同名字区分，一种可能的格式是“ key1=value1 key2=value2 ..."，类似命令行的感觉。但协议传入的参数主要是为了**对齐不同的协议**，如果是所有协议都要配置的参数，如压缩算法，超时时间，重试次数等，就**非常不适合**走协议参数传进去，否则既显著增加了解析的复杂度，也和controller中设置的选项高度重合。

- [x] 协议支持参数
- [ ] 命名服务支持参数
- [ ] 负载均衡支持参数