Add catalog SPI modules and refactor coral-common to SPI dispatch

[wmoustafa]

What changes are proposed in this pull request, and why are they necessary?

This PR introduces a 3-module catalog SPI architecture that decouples Hive and Iceberg implementations from the core classpath. Currently, coral-common bundles hive-metastore, hadoop-common, and iceberg-* as api dependencies, which means every consumer transitively pulls all of them. This refactor isolates catalog-specific code behind an SPI boundary.

New modules:

• coral-catalog-spi — Pure interfaces (CoralCatalog, CoralTable, TableType), the com.linkedin.coral.common.types package, and new SPI contracts (CoralCalciteTableAdapterFactory, CoralCalciteTableAdapterRegistry). Zero Hive/Iceberg dependencies.
• coral-catalog-hive — Hive catalog implementations (HiveTable, HiveCalciteTableAdapter, HiveCalciteViewAdapter, HiveToCoralTypeConverter, TypeConverter) with HiveCalciteTableAdapterFactory registered via META-INF/services.
• coral-catalog-iceberg — Iceberg catalog implementations (IcebergTable, IcebergCalciteTableAdapter, IcebergToCoralTypeConverter, IcebergHiveTableConverter) with IcebergCalciteTableAdapterFactory registered via META-INF/services.

coral-common changes:

• CoralDatabaseSchema.getTable() now uses CoralCalciteTableAdapterRegistry for SPI-based dispatch instead of instanceof checks.
• 9 implementation classes converted to @Deprecated wrappers delegating to the new modules.
• Hive/Hadoop/Iceberg dependencies demoted from api to implementation scope.

Backward compatibility: All original FQCNs still resolve — interfaces/types kept the same package, and implementation classes have @Deprecated wrappers at the old locations. Consumers relying on transitive api exposure of hive-metastore or iceberg-* from coral-common may need to add explicit dependencies.

Known limitations:

• ToRelConverter.toSqlNode(String, Table) still couples the core to Hive's Table type (issue Refactor SQL parsing components to Use CoralTable Instead of Hive Table #575).
• IcebergHiveTableConverter in coral-catalog-iceberg retains implementation deps on Hive as a temporary bridge.

How was this patch tested?

• ./gradlew compileJava — all modules compile successfully
• ./gradlew :coral-common:test — existing tests pass
• Verified ServiceLoader discovers both HiveCalciteTableAdapterFactory and IcebergCalciteTableAdapterFactory
• Confirmed coral-catalog-spi has no Hive/Iceberg on compile classpath
• Verified deprecated wrapper classes at old FQCNs still resolve and delegate correctly

[ruolin59]

actually appears to mostly be moving things around and refactoring, but have a few questions about the module rewiring, and also, it would be good to add some new unit tests to cover the new items introduced in this pr, including

• CoralCalciteTableAdapterRegistryTest: priority ordering, register() merging with ServiceLoader, UnsupportedOperationException on no-match.
• One smoke test per new factory confirming supports() / createAdapter() return the expected adapter class for a representative CoralTable.
• One test per deprecated wrapper confirming new (...) produces an instance assignable to the new type and exposes the same public surface.

[ruolin59]

this method throws UnsupportedOperationException, I'd just like to confirm that this is the new behavior we want (so no catching an return null, correct?), if so, may be a good idea to at least update the javadoc

[ruolin59]

coral-catalog-hive and coral-catalog-iceberg appear to still have api dependencies on hive-metastore and iceberg-core respectively, so the consumer would still be pulling these deps transitively right? To clarify,

1. Was the intent to demote coral-common's project deps to implementation, or is keeping them as api a deliberate compatibility choice?
2. If it's deliberate, which downstream consumers are expected to migrate to depending on coral-catalog-spi directly?
3. Can the redundant implementation block at lines 21-34 be dropped?