[FEATURE] Support Function Signature In Function Anchors

[gord02]

Summary

For plans that could use overloaded functions from the same URN anchor, we need more than just the name to differentiate between them. Currently parsing from text to json drops the type for the function which was found during a round trip test starting from text.

An example is the regexp_match_substring which is overloaded with different parameters.

=== Extensions
URNs:
  @  1: extension:io.substrait:functions_string
  @  2: extension:io.substrait:functions_comparison
Functions:
  #  1 @  2: equal:any_any
  #  2 @  1: like:str_str

=== Plan
Root[timestamp, productID, productDescription]
  Fetch[limit=100, offset=0 => ]
    Project[$1, $0, if_then(equal:any_any($0, 'Dog Toys') -> true, _ -> false)]
      Read[foobar.products => productDescription:string?, timestamp:precisiontimestamp<9>]

[wackywendell]

Yes, we should definitely support that. To clarify, I would suggest:

• In the Extensions section, always include the signature
• In the Plan with verbose mode, always include the signature
• In the Plan without verbose mode, include the signature if it is not unique

So the use of equal:any_any in the plan above would be what we would do in verbose mode, but for the given plan, in non-verbose mode we wouldn't include the function signature because there is only one equal impl in the Extensions. For parsing, either form would be valid and correctly matched - although a function expression in the plan with a name and no signature (equal(…)) would generate a warning if it was not unique in the Extensions.

Note that uniqueness testing has a precedent already: you can have the same function name+signature in two files, in which case the anchor is needed to distinguish; in non-verbose mode, we would then add the anchor: equal:any_any#1.