fix: policy expr type errors due to X.0 floating points in JSON being treated as ints

[j-lanson]

Resolves #449 .

Pernicious bug in policy expression code. JSON has only "Number" type, doesn't distinguish between float and int. When a float that ends in .0 gets serialized then injected into a policy expression, it is treated as an integer. Our policy expression evaluation logic for arithmetic/comparison requires operands be int + int or float + float, so when this bug occurs we get a type error because we do int + float.

This fix updates binary_primitive_op to detect when the operands are int+float or float+int and implicitly upcasts the int to a float. It also removes other type checking from binary_primitive_op, as it was bad design. For example, although we updated fn add to allow DateTime + Span, the type checking in binary_primitive_op did not allow this to occur and we had not tested to encounter this bug before.

Added tests to ensure int+float arithmetic/comparisons return floats, and ensure (add datetime span) does not error.

In a more correct AST design, we would do a first-pass eval of the AST and insert "cast" nodes around integer primitives to make them floats. This fix approach works but doesn't afford per-op control, highlighting the need for #387 .

[alilleybrinker]

Thanks Julian, and yeah I agree on the need for a refactor of this code to address stuff like this more preemptively.