Override supports_expression_index? / supports_index_sort_order? capability flags

[yahonda]

Background

AbstractAdapter declares both supports_expression_index? and supports_index_sort_order? returning false by default. PostgreSQL overrides them to true. oracle-enhanced does NOT override either, so they currently report false despite Oracle Database supporting both since 8i:

• Function-based indexes (CREATE INDEX idx ON t (LOWER(col))) — Oracle 8i+
• Index sort direction (CREATE INDEX idx ON t (col ASC, other DESC)) — Oracle 8i+

oracle-enhanced's add_index already accepts and emits these forms (see quote_column_name_or_expression), but the upstream capability flags say "no" — Rails core may take alternative paths that suppress the feature, and AR-level tests that branch on the flags will skip Oracle paths needlessly.

Proposal

Override both flags to true:

def supports_expression_index?
  true
end

def supports_index_sort_order?
  true
end

Verification

• Confirm add_index :t, "LOWER(col)", name: :idx round-trips through schema dump (already works in practice; this is just to make the capability flag honest)
• Confirm add_index :t, [:col, :other], order: { col: :asc, other: :desc } round-trips
• Add specs that exercise both shapes if not already covered, asserting the SQL contains the expression / ordering

Out of scope

• supports_partial_index? — separate concern, tracked in a sibling issue (Oracle does not have strict partial indexes; only function-based workarounds).
• supports_index_include? — PostgreSQL-only feature (INCLUDE (col) clause).

Why now

Two-line capability-flag override; risk near zero. Surfaced during the survey for #2702 / #2710.