Describe the bug

CEL v0.23.0 introduced cost-tracking for comprehensions along with a handful of other cleanups
to better track size and entry size of various CEL values (#1104). The change also introduced a
change in call order to the custom CostEstimator implementations which unfortunately triggered
failures in clients who estimated CEL scalar types differently from the standard CEL definition.

To Reproduce
Check which components this affects:

• parser
• checker
• interpreter

Sample expression and input that reproduces the issue:

// where self is a map(string, duration)
duration(self.val1) == self.val2

Expected behavior
The expected cost from CEL and Kubernetes (as an example) was off-by-one since CEL always
estimates the size of constants as 1 and in Kubernetes the cost of constants may be zero.

With the call order restored, the cost would be what Kubernetes dictates for the type, not what
the core CEL definitions dictate.