feat: refactor client module to resolve circular dependencies

[DMwangnima]

At the beginning, we planned to resolve circular dependencies by splitting configuration logics of config package to modules that they belong to. For example, move config.RegistryConfig and its configuration logics to registry package, then config package rely on registry package. Please refer to #2377.

But we found that it is difficult to resolve because of the existing of /common/extension module. If we change it, it will be the same as refactoring the whole dubbo-go. This is clearly not the amount of work that the Triple branch can handle.

To present to users the effect of layering and ensure the correctness of user-side API, we decide to take an ugly approach. For example, make a copy of config.RegistryConfig and put it to registry package. In the client module, we expose WithRegistries(registries map[string]*registry.RegistryConfig) to users. But client module would call compatRegsitryConfig to turn registry.RegistryConfig into config.RegistryConfig.

This is a temporary approach. When we decide to refactor dubbo-go, these compatible parts would be removed.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[chickenlj]

LGTM.