Don't collapse a plain decimal literal like 1.0 to an int

[afonsojanu]

Fixes #24.

hjson.loads('{test: 1.0}') currently hands back an int, not a float:

>>> import hjson
>>> hjson.loads('{test: 1.0}')
OrderedDict([('test', 1)])
>>> type(hjson.loads('{test: 1.0}')['test'])
<class 'int'>

That's inconsistent both with the standard json module (which keeps 1.0 a float) and with hjson's own serializer, since hjson.dumps(1.0) already produces "1.0". So a value written with an explicit decimal point doesn't round-trip through loads/dumps.

The cause is in scantfnns in hjson/decoder.py. After parsing the number as a float, it checks whether the result is numerically whole and, if so, casts it down to int:

res = context.parse_float(integer + (frac or '') + (exp or ''))
if int(res) == res and abs(res)<1e10: res = int(res)

This collapse is intentional for a case like 17.01e2, where the exponent pushes an otherwise-fractional value up to a whole number (1701.0 -> 1701), and the existing test fixtures (kan_test.hjson / kan_result.json) already pin that behavior. But the same check also fires for a plain decimal literal such as 1.0 or 10.00, where there's no exponent at all - the decimal point was written on purpose and shouldn't be discarded.

The fix narrows the collapse to only apply when an exponent is present, so it keeps the 17.01e2 -> 1701 behavior but leaves 1.0 and 10.00 as floats.

One existing fixture (comments_test.hjson) had a num2: 0.0 entry whose expected result (comments_result.json / comments_result.hjson) was pinning the old, buggy behavior ("num2": 0 instead of 0.0). Updated both to the correct value.

Added two tests in test_decode.py: one confirming a bare decimal literal stays a float, and one confirming the exponent case still collapses to int as before.

Ran the full suite locally (python -m unittest discover -s hjson/tests), 112 tests, all passing.