feat: add derivation expression evaluator

[tokoko]

Adds support for the evaluation of extension function's return type expressions.
It's meant to be used by producers to correctly infer return types.
It uses antlr grammar (temporarily) copy-pasted from substrait-java w/o changes.

[github-actions]

ACTION NEEDED

Substrait follows the Conventional Commits
specification for
release automation.

The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification.

[tokoko]

Evaluation is not exhaustive yet, I've implemented the types necessary for functions in ibis-substrait and subframe.

Some open questions:

• The term "derivation expression" was borrowed from proto message type describing the concept although the proto itself isn't being used. I'm open to renaming it if there are better alternatives...
• I added antlr4-python3-runtime as required dependency. Should I make it optional?

[tokoko]

@jacques-n FYI

[gforsyth]

I'll try to take a detailed look at this next week (or maybe tomorrow?), but some initial thoughts:

I think leaving the antlr runtime as a required dependency is fine. It's very light-weight, and the likelihood of a given plan not having any scalar functions seems low.

And we should mark the antlr-generated files with linguist-generated

[tokoko]

It's very light-weight, and the likelihood of a given plan not having any scalar functions seems low.

true, but note that this is likely only necessary for producers as output types of ScalarFunction calls are already in the substrait plan, therefore no derivation is needed for a consumer. So we would be adding unnecessary dependency to anyone that's just consuming.

And we should mark the antlr-generated files with linguist-generated

checked and src/substrait/gen/** (parent directory) is already marked as such

[gforsyth]

true, but note that this is likely only necessary for producers as output types of ScalarFunction calls are already in the substrait plan, therefore no derivation is needed for a consumer. So we would be adding unnecessary dependency to anyone that's just consuming.

Ahh, right. OK, well, I'm good with making it an optional dependency.

[tokoko]

I'm thinking of calling the extra extensions as the forthcoming ExtensionRegistry (next PR) will almost always be how this functionality is accessed by the users. Plus it will also require other dependencies (mainly pyyaml), simpler to put them both in a single extra.

[EpsilonPrime]

When we move this into core we should use:

options {
    caseInsensitive = true;
}

so we can eliminate all these fragments.

[tokoko]

I can open an issue in substrait-java for this..

[tokoko]

@gforsyth just a reminder

[gforsyth]

Thanks for the ping @tokoko and sorry for the delay in getting to this.