REST: Add spatial expressions to REST Catalog OpenAPI Spec

[Kontinuation]

This PR updates the REST Catalog OpenAPI specification to support spatial predicate operators and bounding box literals. This change aligns the REST spec with the core Iceberg expression updates proposed in #14101.

Changes:

• Added st-intersects and st-disjoint to the allowed ExpressionType enum.
• Added new schemas for bounding box literal.

Here is an example of proposed JSON representation of spatial filter:

{
  "type": "st-intersects",
  "term": "column-name",
  "value": {
    "x": {
      "min": 1.0,
      "max": 3.0
    },
    "y": {
      "min": 2.0,
      "max": 4.0
    },
    "z": {
      "min": 3.0,
      "max": 5.0
    },
    "m": {
      "min": 4.0,
      "max": 6.0
    }
  }
}

[singhpk234]

Thanks @Kontinuation for the PR
since its the spec change can you please open a dev discuss thread for this ?
we would use this expression in the remote scan planning as a filter ? do you have any other use case in mind ?

[Kontinuation]

The spec change is coupled with the design of spatial predicates and bounding box literals in #14101, so I'd like to start a dev thread once we reach consensus in that PR.

We currently don't have use cases such as remote scan planning, this stems naturally when adding new predicate operators and literal types, the new predicates need to have a representation in the REST Catalog OpenAPI.

[nastra]

I think we first need to finalize #14101 before we can discuss how this looks exactly at the REST layer (you can probably decouple the ExpressionParser changes from #14101 so that those changes can be done after the spec has been voted on): I was thinking of the following steps:

• finalize API, Core: Add geospatial predicates and bounding box literals #14101 (without changes to ExpressionParser)
• finalize and vote on REST: Add spatial expressions to REST Catalog OpenAPI Spec #14856
• add ExpressionParser changes