从CSE 1.X 升级到 CSE 2.X后，接口配置的swagger注解@ApiImplicitParams 参数失效

### 问题背景：
从CSE 1.X 升级到 CSE 2.X后，接口配置的swagger注解@ApiImplicitParams 参数失效
接口定义如下：
```java
@RequestMapping(path = "/v1/test", method = RequestMethod.POST, produces = MediaType.APPLICATION_JSON_VALUE)
@ApiImplicitParams(value = {
@ApiImplicitParam(name = "x-test-header", dataType = "string", required = false,
paramType = "header", value = "xxx",
allowableValues = "true,false")})
public String testV1(HttpServletRequest request) {
return "ok";
}
```
使用CSE 1.X时，如果传入的header不是true或者false，报错如下：
```json
{
"message": "Parameter is not valid for operation [XXX.XXX.testV1]. Parameter is [x-test-header]. Processor is [header]."
}
```
使用CSE 3.X时，接口无报错

### 问题分析：
通过对比CSE 1.X和2.X的代码，发现org.apache.servicecomb.common.rest.codec.RestCodec#restToArgs将request请求转发为请求对象的过程中，org.apache.servicecomb.common.rest.definition.RestOperationMeta#init中创建Type的代码进行了调整
从
```
Method method = operationMeta.getMethod();
Type[] genericParamTypes = method.getGenericParameterTypes();
```
调整为
```
(Type)operationMeta.getSwaggerProducerOperation().getSwaggerParameterTypes().get(parameter.getName())
```
导致type丢失了枚举信息

请帮忙确认是否需要跟CSE 1.X保持兼容以及其他类似注解是否有相同问题

从 org.apache.servicecomb.common.rest.codec.RestCodec#restToArgs 和 RestOperationMeta#init 开始，然后比较 issue 中展示的 CSE 1.X 和 2.X 类型创建路径。检查 Swagger @ApiImplicitParams allowableValues 及相关注解在 CSE 2.X 和 3.X 中是如何表示的。完成的标准是确定是否需要与 1.X 的验证兼容性，并确认类似注解是否会丢失 enum 信息。

由索引模型根据 Issue 内容生成。