[SPARK-50964][SQL] Use StaticInvoke to implement VariantGet codegen

[panbingkun]

What changes were proposed in this pull request?

The pr aims to

• use StaticInvoke to implement VariantGet codegen.
• support for non-literal paths in VariantGet.

Why are the changes needed?

Based on @cloud-fan's suggestion, using StaticInvoke to implement VariantGet codegen, it can simplify the code.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

• Pass GA.
• Manually check, eg: VariantSuite, VariantExpressionSuite

Was this patch authored or co-authored using generative AI tooling?

No.

[panbingkun]

cc @cloud-fan @chenhao-db @harshmotw-db @HyukjinKwon

[chenhao-db]

PushVariantIntoScanSuite is failing due to the change - it only recognizes VariantGet, but not the replaced expression (replacing runtime-replaceable expression happens before the rule). Essentially, I don't really think this change is a good idea. The implementation of VariantGet is simplified only by a bit, which is fixed and not likely to change, but the optimizer rules will get more complex (and there may be more rules targeting VariantGet in the future).

[panbingkun]

PushVariantIntoScanSuite is failing due to the change - it only recognizes VariantGet, but not the replaced expression (replacing runtime-replaceable expression happens before the rule). Essentially, I don't really think this change is a good idea. The implementation of VariantGet is simplified only by a bit, which is fixed and not likely to change, but the optimizer rules will get more complex (and there may be more rules targeting VariantGet in the future).

I have fixed it, and another benefit of it is that when the path is foldable, it will run in ConstantFolding, thereby avoiding eval it every time and improving performance.

@cloud-fan

[cloud-fan]

This is likely the most annoying part of RuntimeReplaceable: pattern match becomes less intuitive.

Now I think it's probably better not to use RuntimeReplaceable for expressions that need be matched post analysis, until we improve RuntimeReplaceable to be replaced truly at runtime.

[panbingkun]

Let's hold it first, and I'll try to investigate how to make a truly RuntimeReplaceable (as we discussed privately, I think its idea is to only execute the replaced expression at runtime, while still maintaining it during the analysis and optimization stages, right?)

[cloud-fan]

Yes, that will be the best.