[Task] Invert shenyu-registry-core dependencies and load registry implementations explicitly #7311

Background

shenyu-registry-core contains a single SPI-backed factory, but its POM directly depends on every registry implementation:

• ZooKeeper;
• etcd;
• Consul;
• Nacos;
• Polaris;
• Eureka;
• Kubernetes.

This reverses the intended SPI dependency direction. Any consumer of shenyu-registry-core—including admin, SDK, Feign SDK, and the registry starter—receives all registry clients and their transitive dependencies even when only one implementation is configured.

The desired direction is:

registry-api <- registry-core
                       ^
                       |
        registry-nacos / consul / etcd / ...

Related extension migrations: #7305 and #7308.

Scope

Core dependency inversion

• Remove all concrete shenyu-registry-* implementation dependencies from shenyu-registry-core.
• Keep only the registry API, ShenYu SPI support, and factory/cache behavior needed to locate an implementation already present on the classpath.
• Preserve existing SPI resource names and registration keys.
• Produce a clear error when a configured implementation is not present instead of failing with an opaque null/class-loading error.

Consumer and starter model

• Introduce explicit dependency/starter choices for each supported registry implementation, or document direct implementation dependencies.
• Preserve shenyu-spring-boot-starter-registry compatibility for a documented transition window. If it remains an all-in-one starter temporarily, move aggregate dependencies into that starter rather than back into core.
• Update admin, SDK core, SDK Feign, examples, and integration tests to declare only the implementation(s) they actually exercise.
• Ensure plugin-store extensions can provide a registry SPI implementation without modifying registry-core.
• Document how users select one or multiple registry implementations.

Dependency and release hygiene

• Add dependency-tree checks proving shenyu-registry-core does not pull ZooKeeper, etcd, Consul, Nacos, Polaris, Eureka, or Kubernetes clients.
• Update LICENSE/NOTICE and distribution dependency inventories after the transitive graph changes.
• Add migration and rollback notes for users relying on the old implicit all-implementation classpath.

Verification

• Unit-test factory behavior with no implementation, one implementation, multiple implementations, reinitialization, and missing/unknown register types.
• Run SPI discovery tests for every in-repository implementation.
• Run targeted admin, SDK, and starter tests.
• Run representative instance registration/discovery integration tests.
• Verify Consul/Polaris external implementations remain discoverable through the same API.
• Run full build, Checkstyle, RAT, and distribution packaging checks.

Acceptance Criteria

• shenyu-registry-core has no concrete registry implementation dependency.
• Core contains only API/SPI/factory responsibilities.
• Each runtime consumer explicitly selects its registry implementation.
• Existing starter users have a documented non-breaking transition path.
• Missing implementations fail with a clear actionable error.
• Per-implementation SPI and integration tests pass.
• Dependency-tree assertions prevent future implementation aggregation in core.
• LICENSE/NOTICE and release dependency inventories are updated.