注解支持解析origin和自定义resource name

这个注解功能已经实现，讨论下有没有必要合并进来。

1、被注解保护的资源，可以通过解析orgin方法提取出入参中的某个值作为资源标识。
2、被注解保护的资源，可以通过解析resource name的方法从入参中提取资源名称。

我们的场景：
注解可以灵活的定义资源名称和origin，给使用注解的业务系统提供了很大的灵活性；例如某个service的接口，提供给多个调用方（a/b/c），可以直接通过提取资源名称的方法，把resource绑定到对应的调用方上(serviceApi_a,serviceApi_b,serviceApi_c)，分别对其进行限流规则配置。也可以通过解析orgin方法，统一为一个资源，分别配置不同的origin进行规则配置。

关于origin只在最外层生效和统一拦截器冲突问题：
origin仅会在入口处生效，假设web系统有统一的filter处理入口请求并且加上了sentinel限流保护，那么注解中的origin也就不生效了。我是这么想的。

1、对于统一filter，可以制定统一的规范提取某个字段作为origin的标识。
2、让filter可配置开闭让用户选择；解决filter定义的统一origin提取规范对某些业务系统来说改造成本过高问题(比如业务系统有一些历史包袱，识别调用者身份的字段所处的位置千奇百怪)
3、注解支持了origin解析，同时具备了灵活性，未必所有的入口都需要限流保护。

Start by locating the existing annotation implementation and the entry-point interceptor or filter mentioned in the issue. Review how resource names and origins are currently obtained, then clarify the proposed extraction API, precedence, and configuration behavior. The issue is complete only when the maintainers agree on scope and expected tests; no file or test is named here.

Written by the indexing model from the issue text.