Implement uncertainty

[EvanMachusak]

We don't implement uncertainty in the same way as the other two open source implementations, and this will cause testing differences that would be otherwise unresolvable.

We need to replace the use of int?, long?, and decimal? as the default bound types for the ELM System.Integer, System.Long, and System.Decimal types respectively to CQL types like CqlInteger, CqlLong, and CqlDecimal. These new structures need to contain their primitive value, and must also contain a property that can contain the uncertainty range. When the uncertainty range is needed and is populated, the result value is considered uncertain. Uncertainty will need to be taken into account in a myriad of operators, mainly boolean comparison operators.

These types should be implicitly convertible from their respective primitive types. It is not clear whether they should be implicitly convertible to their primitive types, since when they are uncertain, we would be collapsing a range down to a scalar value. It may be reasonable to return null in such cases, or throw a runtime exception. It may also be preferable to make the cast possible but explicit.

We will need comparers and type converters implemented for these new types.

The signatures of all of the ICqlOperators interface will need to have their primitive return types changed to use these structures so that uncertainty can be propagated.

This is a significant change and will result in a large pull request.

[ewoutkramer]

BTW: this will be added to the language as an official Uncertain type, so I propose we do not act until that's official.