Allow uncertainty arguments for various type casting operations

This is an interesting one. Looking at the spec, ToDecimal only accepts a Boolean or a String, neither of which can be expressed as an uncertainty. But I see that the test cases you created cause the CQL-to-ELM translator to automatically insert a ToDecimal call, passing in an uncertainty -- so it seems the translator may invoke things technically not in the spec!

I guess we probably should support something like this for some of the other ToXXX functions, particularly those that can take an argument that can be represented by an Uncertainty. That would be:

ToBoolean(argument Decimal) Boolean
ToBoolean(argument Integer) Boolean
ToDate(argument DateTime) Date
ToDateTime(argument Date) DateTime
ToQuantity(argument Decimal) Quantity
ToQuantity(argument Integer) Quantity

I think I would also add ToInteger, because I think the translator maybe would use something like that to try to convert a Decimal to an Integer.

I left toString off the list because the spec does not define how to translate and uncertainty to a String and it also says that the string must be "round-trippable" back to its original type.

All the said, I think it's outside the scope of this task. So I'd suggest we create another bug to track it.

Originally posted by @cmoesel in https://github.com/cqframework/cql-execution/pull/222#discussion_r577873597

Start by reviewing the CQL-to-ELM translator behavior that inserts ToDecimal calls with uncertainties, then compare the listed ToBoolean, ToDate, ToDateTime, ToQuantity, and ToInteger cases with the specification. Done means the supported conversions and their uncertainty behavior are defined and verified without extending ToString.