fix: accept whole numbers for the formats float and double

[jnbdz]

Motivation

As discussed in #112: the formats float and double define the precision of a number, not its lexical representation. Jackson parses JSON numbers without a decimal part into Integer/Long, so a value like 10 for a { "type": "number", "format": "float" } property was rejected with Number does not match the format "float", although 10 is a valid number with float precision. This is a common real-world case, since many serializers emit 25.0 as 25.

Changes

Following the approach suggested in the issue discussion (relax the checks in OpenAPIFormatValidator, bounded by the exactly representable integer range):

• Integer/Long instances are now accepted for the formats float and double, as long as the value is exactly representable with the related precision: |value| ≤ 2^24 for float, |value| ≤ 2^53 for double. Larger whole numbers are still rejected, so no information is lost silently.
• The behaviour for all other instance types is unchanged (including the NaN/Infinity rejection and the int32/int64 checks).

Test cases cover whole numbers for both formats (including the cases from #113), the exact-representability boundaries in both directions (2^24/2^53 accepted, 2^24 + 1/2^53 + 1 rejected), and Integer.MAX_VALUE/Long.MAX_VALUE rejection.

Fixes #112