feature: support custom activation implementation

[yangminzhu]

Activation doesn't support customization of its implementation which is useful and needed when there are large number of attributes but only a small part of them are used in the evaluation.
In this case we may want to avoid copying all the unused attributes before evaluation. If customization is supported, a user could have their own Activation implementation and then dispatch the attribute look-up dynamically. This also opens more flexibility on the usage of the Activation.

The easiest way might be just to add the virtual keyword to the following functions.

  // Provide value that is bound to the name, if found.
  // arena parameter is provided to support the case when we want to pass the
  // ownership of returned object ( Message/List/Map ) to Evaluator.
  absl::optional<CelValue> FindValue(absl::string_view name,
                                     google::protobuf::Arena* arena) const;

  // Insert value into Activation.
  void InsertValue(absl::string_view name, const CelValue& value);

  // Insert ValueProducer into Activation.
  void InsertValueProducer(absl::string_view name,
                           std::unique_ptr<CelValueProducer> value_producer);

  // Removes value or producer, returns true if entry with the name was found
  bool RemoveValueEntry(absl::string_view name);

Similar to the Activation interface in golang:
https://github.com/google/cel-go/blob/ebbdb2886430bee8aa24a7f83a4ecb99db312478/interpreter/activation.go#L28

@kyessenov @TristonianJones Any thoughts on this? I'm still learning the CEL library so please let me know if I missed anything important or if this is already supported in cpp. Thank you.

[TristonianJones]

This sounds like a reasonable request. @kyessenov what do you think?

[kyessenov]

Yes, it's reasonable for a very large activation. However, there might be a way to share activations between evaluations, amortizing the cost of evaluation. The names in the activation pairs are generally not dynamic (e.g. checking needs the types for names), so they do not change from an evaluation to an evaluation, and the value producer can generate new values each time.