## Motivation

Currently, CEL-C++ only supports Type-level function overload resolution
during the type-checking phase, while runtime function dispatch is limited
to Kind-level resolution. This limitation prevents runtime selection of
the most appropriate function overload when dealing with complex type
hierarchies or when type information is available but not fully determined
during static analysis.

As described in issue google#1484, the FunctionRegistry cannot distinguish overloads
differing only by container parameter types (e.g., `list<int>` vs `list<string>`)
because the current implementation only compares `cel::Kind` rather than precise
`cel::Type` information during function registration and dispatch.

## Objective

Enable runtime function overload resolution based on precise Type information
by propagating overload IDs from the type-checking phase to the runtime
execution phase. This enhancement allows the runtime to make more informed
decisions about which function overload to invoke, improving both correctness
and performance in scenarios where multiple overloads are available.

## Implementation

### Core Changes

1. **Enhanced Function Interface**
   - Extended `Function::Invoke()` method signature to accept an optional
     `overload_id` parameter (`absl::Span<const std::string>`) with default empty value
   - Updated all function adapter classes (Nullary, Unary, Binary, Ternary, Quaternary)
     to propagate overload ID information
   - Modified `CelFunction` implementation to support the new interface

2. **FlatExpr Builder Integration**
   - Added `reference_map_` field to `FlatExprVisitor` to access type-checking
     reference information during expression compilation
   - Implemented `FindReference()` helper method to retrieve overload IDs
     associated with specific expressions
   - Updated `CreateFunctionStep()` and `CreateDirectFunctionStep()` calls
     to pass overload ID information from the reference map
   - Added default parameter values to maintain backward compatibility

3. **Function Step Enhancement**
   - Extended `AbstractFunctionStep` constructor to accept overload IDs with move semantics
   - Updated both eager (`EagerFunctionStep`) and lazy (`LazyFunctionStep`)
     function step implementations to store overload ID information
   - Modified direct execution steps (`DirectFunctionStepImpl`) to store
     and utilize overload ID information
   - Enhanced the `Invoke()` helper function to pass overload IDs to the
     underlying function implementation

### Technical Details

- **Backward Compatibility**: All function creation methods provide default
  empty overload ID parameters, ensuring existing code continues to work
  without modification

## Benefits

1. **Enhanced Precision**: Runtime can select optimal function overloads
   based on complete type information rather than just value kinds
2. **Better Performance**: Reduced need for runtime type checks and
   fallback mechanisms when precise overload information is available
3. **Improved Extensibility**: Framework for future enhancements requiring
   type-aware runtime behavior
4. **Maintained Compatibility**: All existing functionality preserved
   while adding new capabilities
5. **Resolves Container Type Disambiguation**: Enables proper handling of
   function overloads that differ only in container element types, addressing
   the "empty container" problem described in the issue

## Testing

This change maintains full API and ABI compatibility through default parameter
values. All existing tests should continue to pass without modification, and
new tests can be added to verify type-aware overload resolution behavior.

Closes google#1484