Asynchronous function invocation support

[TristonianJones]

The PR introduces support for asynchronous functions as CEL extensions.

The general algorithm for evaluation relies on the types.Unknown value to indicate when
async calls relevant to the outcome of an expression. Async calls arguments are tracked,
deduped, and memoized based on the overload id associated with the implementation.

It is possible to use partial state evaluation with async evaluation, though async calls will
be resolved before any unknown attribute patterns. Using both features together may be
inefficient; however, there is a general expectation that async function implementations may
implement their own caching logic in order to handle repeated invocations of the same
async function with the same arguments.

[TristonianJones]

While this PR does not specifically attempt to address #356, it is possible to use the functions.AsyncOp implementation to solve this problem. The only caveat is that there is likely a 2x performance penalty for using the functions.AsyncOp purely for plumbing Activation data into a synchronous function.

[TristonianJones]

FYI @mswest46

[JimLarson]

Per our conversation:

It looks like there are a few separate features here which can largely be used independently:

• a result cache which can be used by expensive functions;
• parallel execution for high-latency calls;
• a potentially arbitrary argument passed in at the top level and propagated to specially-declared extension functions.
  • Due to strange golang magic, restricted to be just context.Context, but hey, as long as you're digging one tunnel, why not build a parallel shaft and plumb through a interface{}? Consider it.
  • Even though context.Context allows arbitrary key/value pairs to piggyback on it, use of this as a general-purpose optional argument is contra-indicated in its docs.

At a minimum, consider allowing these functions to be used in the API independently.

Consider also having the result cache be implemented as a wrapper layer exploiting the plumbed-through interface{} for the cache. Yes, for peak efficiency you'd want this a little more integrated when you're using it with parallelism, so you can avoid creating a new goroutine when there'd be a cache hit, but in cases where the cache is useful this overhead is probably negligible, so it might be worthwhile for the cleaner stratification of features. OTOH, the deeper integration might not be that much more complex.

Consider having these new features just be enabled/disabled at each extension function, maintaining just one kind of Program.

Lastly, these all need better names and documentation. It's not an async function since you're never returning from the call stack. The docs need to make it clear what's being implemented here.

[JimLarson]

It's odd to have the comma between the comment and the field it documents, here and below.

[JimLarson]

It's unclear what an "asynchronous extension function" is.