Rethink design of `eval` API with respect to parameter nullability

[hatyo]

in Value we have the following eval method:

<M extends Message> Object eval(@Nonnull FDBRecordStoreBase<M> store, @Nonnull EvaluationContext context);

The first parameter store is marked as Nonnull, but compile-time Values need only the context to be able to evaluate their output. This forces us when e.g. designing and API such as CompileTimeValue to bypass this and mark the store as Nullable.

The same situation is encountered in #2019 when extending QueryPredicate to add compileTimeEval.