397 fix forward references in expressionbuilder 4

[ewoutkramer]

One more effort.

This PR now builds upon my work, based on Evan's work based on Paul's work based on my work.

To review this, it is good to note that I made only subtle changes to Evan's work on the branch:

• InvokeDefinedFunctionThroughRuntimeContext is mostly untouched, but I needed to add logic to turn function calls with a choice type as an argument (type object) into calls where those parameters are cast to their expected parameter type. I also made sure the Firely-specific DataType type is no longer used for choice types, but we'll stick to object everywhere.
• I changed TypeFor to add corrections for things specific to the Firely model. This code is only necessary because the Cql2Elm Java stack leaves out resultTypes, and it will need to go in the end - issues have been created to make more definitive fixes.
• I added two new corrections: we are trying to add signatures where they are missing (necessary for function calls where the argument is a choice) and a correction for incorrect ELM generated when using bound QICore valuesets.

⚠️ All Paul's and Evan's work on these branches should be in and were left alone, except the few things paul added to the -3 branch after Evan branched off -4. We'll need to cherry pick those changes once this is in. ⚠️

This PR enables the translation of FunctionRef/ExpressionRef to rely on the ref's resultTypeSpecifier instead of having to look the definition up in the DefinitionDictionary. Not using the DefinitionDictionary avoids running into the situation where the ref is a forwards reference whereby the DefinitionDictionary does not yet contain the translated function we want to call.

This PR uses the recent functionality added to LibrarySet to lookup a symbol, and expands this to be able to lookup functions by signature. Given the function name in the FUnctionRef/ExpressionRef, and, in the case of an overload, the signature, we can now lookup any function defined in any library in the LibrarySet, so we can copy over the resultTypeSpecifier.

Filling out this resultTypeSpecifier is now done in a pre-processing step, happening when we are constructing the LibrarySet. The pre-processing step will find all Refs, and then do this:

Try to find the function by name. If it is not an overload, use the resultTypeSpecifier If there is an overload, use the Ref's signature, if available. If there is no signature, use the types from the Ref's parameters and match on those. Otherwise, we cannot find the overload, and we will raise an error. This ensures that after the pre-processor has run, all Refs > have a resultTypeSpecifier, and we can depend on that fact.

This PR re-uses the OverloadedFunctionDefinition, and there are some updates to the CanCombine function to make sure the pre-processor fix and the CanCombine use the same criteria.

I also added a bunch of useful extension methods for working with the Elm function elements and signatures.

[baseTwo]

I'm temporarily changing the target branch to the 3rd branch in the series of PR's, to see the differences that @ewoutkramer talked about more clearly. Once reviewed, it can be changed back to develop-2.0 before merging

[baseTwo]

I'm changing the base back to develop-2.0