Use overload_id for checked function overload resolution

[xjasonli]

Fixes #1484.

This is a follow-up to #1530, rewritten around the approach suggested in that discussion.

The previous version tried to pass overload information through the runtime function invocation path. That made the overridable function interface harder to keep compatible. This version takes a different route: FlatExprBuilder uses the checker’s overload_id information to narrow the candidate set ahead of time, and the runtime registry records which overload ID each implementation handles.

This PR is a bit large because the registry, planner, runtime dispatch, standard function registrations, and tests need to move together to keep the tree green. If this is too large to review or sync comfortably, I am happy to discuss how to split it into smaller reviewable pieces.

What changed

This PR adds overload_id-aware function overload resolution for checked expressions:

• FunctionDescriptor can carry an overload_id and full cel::Type information.
• FunctionRegistry can look up static and lazy overloads by overload ID.
• ActivationInterface can look up activation-provided overloads by overload ID.
• FlatExprBuilder reads overload IDs from the checked expression reference_map and prefers the overloads selected by the checker.
• Runtime matching still validates actual argument values and keeps fallback candidates for dyn/runtime mismatch cases.

This PR also annotates standard library, optional types, and extension runtime function registrations with the overload IDs declared by the checker.

Why

Today, checked expressions can contain more precise overload information than the runtime normally uses during dispatch. For example, the checker may distinguish overloads such as list<int> and list<string>, while the default runtime matching path only sees both arguments as cel::Kind::kList.

This change uses a two-part approach:

• At plan time, checked-expression overload_id data narrows the candidate set to the overloads selected by the checker.
• At runtime, enable_type_level_overload can enable type-level verification for cases where precise container element/key/value types matter.

The overload_id path also helps with empty containers, where runtime values may not carry enough element/key/value type information to disambiguate overloads on their own.

Compatibility

The main compatibility note is FunctionDescriptor:

• FunctionDescriptor::types() now returns const std::vector<cel::Type>&.
• FunctionDescriptor::kinds() returns the previous kind-level view: const std::vector<cel::Kind>&.

Apart from that API adjustment, the runtime behavior is intended to stay compatible by default:

• overload_id-based candidate filtering is used for checked expressions when reference_map overload information is available.
• Kind-level runtime matching remains the default because RuntimeOptions::enable_type_level_overload defaults to false.
• Type-level runtime matching is only enabled when RuntimeOptions::enable_type_level_overload is set to true.
• Functions without overload IDs continue to use the existing arity/kind fallback matching path.

[xjasonli]

Hi @jnthntatum, cc @jcking — I’ve rebased this PR onto the latest master and force-pushed the updated commits.

The changes remain separated into two commits:

1. Overload ID resolution infrastructure and optional type-level runtime matching.
2. Runtime overload ID annotations for standard library, optional type, and extension functions.

All tests pass locally with bazel test //....

The Cloud Build check currently reports “Needs /gcbrun from a collaborator,” and the workflow security scan is awaiting maintainer approval. Could a collaborator help trigger these checks?

Following your guidance in #1530, this implementation uses plan-time overload selection and registry metadata without changing the function invocation interface. I’d appreciate feedback on whether the current approach and commit boundaries are suitable for review and Piper synchronization, or whether smaller dependent PRs would be preferable.

Two compatibility points I’d particularly like to confirm:

• Checked-expression overload ID selection is currently enabled by default; only type-level runtime matching is opt-in. Should plan-time selection also be gated by an interpreter option?
• FunctionDescriptor::types() now returns cel::Type values, with kinds() exposing the previous view. Would you prefer preserving the existing accessor and adding a separate accessor for full types?

I’m happy to coordinate the integration steps here or in #1484. Thanks for your time!