[SPARK-52729][SQL][FOLLOWUP] Introduce RelationInfo as a common base for TableInfo and ViewInfo

[cloud-fan]

What changes were proposed in this pull request?

This is a follow-up of #52729 (which introduced ViewInfo extends TableInfo).

Previously ViewInfo extended TableInfo purely so that a MetadataTable (which wraps a TableInfo) could also carry a ViewInfo, enabling the single-RPC TableViewCatalog#loadTableOrView perf path. The side effect was that ViewInfo inherited table-only state that is meaningless for views: partitions() / constraints() accessors (returning empty arrays) and the withPartitions / withConstraints / withProvider / withLocation builder setters (callable on a view builder but semantically wrong).

This PR makes TableInfo and ViewInfo sibling subclasses of a new common base instead:

RelationInfo (abstract)                 // columns, schema(), properties()
  + BaseBuilder<B>                       // withColumns/withSchema/withProperties
                                         //   withComment/withCollation/withOwner/withTableType
  |-- TableInfo extends RelationInfo     // adds partitions, constraints
  |     + Builder                        //   adds withPartitions/withConstraints/withProvider/withLocation
  +-- ViewInfo extends RelationInfo      // adds queryText, sqlConfigs, schemaMode, ... viewDependencies
        + Builder                        //   adds the view setters only

MetadataTable now wraps a RelationInfo, and getTableInfo() is renamed to getRelationInfo(). Its partitioning() / constraints() return empty for a non-TableInfo payload. The single-RPC perf path is preserved unchanged; consumers discriminate via getRelationInfo() instanceof ViewInfo (was getTableInfo() instanceof ViewInfo).

Callers updated accordingly: TableViewCatalog default methods, Analyzer, RelationResolution, V1Table, and the in-tree test catalogs.

Why are the changes needed?

ViewInfo IS-A TableInfo is not a true relationship -- a view is not a table. The inheritance forced all of TableInfo's state into the shared builder, leaking table-only operations onto the view surface. Modeling both as siblings of RelationInfo removes the leak at compile time and keeps each builder scoped to exactly what its kind needs, while preserving the MetadataTable carrier that the loadTableOrView perf path relies on.

Does this PR introduce any user-facing change?

No. The affected APIs (TableInfo, ViewInfo, MetadataTable, TableViewCatalog) are @Evolving and unreleased (@since 4.2.0).

How was this patch tested?

Existing tests. catalyst, sql/core, and their test sources compile against the refactored hierarchy; the in-tree TableViewCatalog test implementations were updated to store the common RelationInfo type.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Opus 4.8)