[Enhancement] Design and Implementation of dubbogo-contrib

This is a place for various extensions in the dubbogo ecosystem that aren't part of the dubbogo core.
目前现状：
1.dubbogo中各个扩展都在一个包内，导致dubbogo目前主仓库臃肿
2.各个扩展麻烦，不易维护
3.对于dubbogo来说，这是一次极大的优化，无论是在性能和用户体验
1.设计方案
dubbogo已经通过社区开发者的支持，完成了 ETCD、ZooKeeper、Eureka、Consul、Nacos、Polaris 多种服务发现模式，当然也支持注册中心模式，建立起了强大且完备的社区生态，供用户按需灵活选用。

更多服务发现组件参看扩展仓库：dubbogoContrib-nacos。
现在本身就可以插件化，dubbo-go可能要先单独设计出来一个 dubbogo-spi，dubbo插件的 interface 定义，单独拎出来 dubbogo 依赖 dubbo-spi，插件依赖 dubbo-spi，用户引入对应插件 go.mod 即可自动启用 ，以不调整用户的使用方式为最小代价实现。
除了组件和仓库。dubbogo启动流程也可以考虑精简，做到最小可运行集合足够小，就一个rpc，其他微服务和配置可插拔。
具体实现：
1.设想一个经典的dubbo-go示例就是这个最小集合的rpc使用方式，纯api。

2.微服务、治理、配置组装、多协议和各种能力和示例

使用方式
以 原有的注册为例

import (
"github.com/dubbogo/gost/log/logger"

perrors "github.com/pkg/errors"

api "github.com/polarismesh/polaris-go"
"github.com/polarismesh/polaris-go/pkg/model"
)

import (
"dubbo.apache.org/dubbo-go/v3/common"
"dubbo.apache.org/dubbo-go/v3/common/constant"
"dubbo.apache.org/dubbo-go/v3/common/extension"
"dubbo.apache.org/dubbo-go/v3/registry"
"dubbo.apache.org/dubbo-go/v3/remoting"
"dubbo.apache.org/dubbo-go/v3/remoting/polaris"
)

const (
RegistryConnDelay = 3
defaultHeartbeatIntervalSec = 5
)

func init() {
extension.SetRegistry(constant.PolarisKey, newPolarisRegistry)
}

// newPolarisRegistry will create new instance
func newPolarisRegistry(url *common.URL) (registry.Registry, error) {
if err := polaris.InitSDKContext(url); err != nil {
return &polarisRegistry{}, err
}

providerApi, err := polaris.GetProviderAPI()
if err != nil {
return nil, err
}

consumerApi, err := polaris.GetConsumerAPI()
if err != nil {
return nil, err
}

pRegistry := &polarisRegistry{
url: url,
namespace: url.GetParam(constant.RegistryNamespaceKey, constant.PolarisDefaultNamespace),
provider: providerApi,
consumer: consumerApi,
registryUrls: make([]*common.URL, 0, 4),
watchers: map[string]*PolarisServiceWatcher{},
}

return pRegistry, nil
}

type polarisRegistry struct {
namespace string
url *common.URL
consumer api.ConsumerAPI
provider api.ProviderAPI
lock sync.RWMutex
registryUrls []*common.URL
listenerLock sync.RWMutex
watchers map[string]*PolarisServiceWatcher
}

// Register will register the service @url to its polaris registry center.
func (pr *polarisRegistry) Register(url *common.URL) error {
if getCategory(url) != "providers" {
return nil
}

serviceName := url.Interface()
request := createRegisterParam(url, serviceName)
request.Namespace = pr.namespace
resp, err := pr.provider.RegisterInstance(request)
if err != nil {
return err
}

if resp.Existed {
logger.Warnf("instance already regist, namespace:%+v, service:%+v, host:%+v, port:%+v",
request.Namespace, request.Service, request.Host, request.Port)
}
url.SetParam(constant.PolarisInstanceID, resp.InstanceID)

pr.lock.Lock()
pr.registryUrls = append(pr.registryUrls, url)
pr.lock.Unlock()

return nil
}

dubbogo框架提供服务注册与发现的扩展，目前已经支持与业界主流注册中心对接。
dubbogo完成了 ETCD、ZooKeeper、Eureka、Consul、Nacos、Polaris 多种服务发现模式，当然也支持 DNS 解析以及 Static IP 直连访问模式，建立起了强大且完备的社区生态，供用户按需灵活选用。
更多服务发现组件参看扩展仓库：dubbogo-contrib/registry-nacos

以 DNS Resolver 为例
import (...
dns "github.com/dubbogo-contrib/resolver-dns"
)
func main() {...
client, err := echo.NewClient("echo", client.WithResolver(dns.NewDNSResolver()))
if err != nil {
log.Fatal(err)}
...}

import (
"github.com/dubbogo/gost/log/logger"

perrors "github.com/pkg/errors"

api "github.com/dubbogoContrib-polaris/polaris-go"
"github.com/polarismesh/polaris-go/pkg/model"
)

import (
"dubbo.apache.org/dubbo-go/v3/common"
"dubbo.apache.org/dubbo-go/v3/common/constant"
"dubbo.apache.org/dubbo-go/v3/common/extension"
"dubbo.apache.org/dubbo-go/v3/registry"
"dubbo.apache.org/dubbo-go/v3/remoting"
"dubbo.apache.org/dubbo-go/v3/remoting/polaris"
)
Copy
具体实现：以polaris为例，设计出以polaris为例的dubbogoContrib-polaris扩展，目前打算先实现dubbogoContrib-polaris扩展后，继续其他扩展。

The proposal names no concrete files or tests; start by examining the existing common/extension registration path and module dependencies in go.mod. Compare the current registry integrations with the proposed dubbogo-spi and contrib modules. Done would mean a defined minimal RPC core, separately maintained extensions, and an example showing the intended import and registration flow.

Written by the indexing model from the issue text.