Decode a scalar float16 as a half rather than as an int16

[nebkat]

loadb returns an integer for a lone float16: the bytes 00 4d, meaning 20.0, decode as 19712. A float16 inside a typed array is already correct, so this only ever affected a scalar.

>>> import bjdata, struct
>>> bjdata.loadb(b'{U\x01x' + b'h' + struct.pack('<e', 20.0) + b'}')
{'x': 19712}          # expected {'x': 20.0}

Both implementations have it, in the same way — the marker letter is used as the struct format letter, and h in struct is a signed short while half is e. The C extension falls through into the TYPE_UINT16 case in _bjdata_decode_value, and the pure-Python decoder maps TYPE_FLOAT16 to "h" in __UNPACK_FLOAT16 and __DTYPE_MAP. The numpy dtype maps on both sides already say f2, which is why the typed-array path escaped.

Binary_JData_Specification.md in this repo gives h as 3 bytes of IEEE 754 half in little-endian order, so the decoder contradicted the bundled spec.

The fix adds _pyfuncs_ubj_PyFloat_Unpack2 beside the existing Unpack4 and Unpack8. Unlike those two it has no native-format branch: they decode by hand only where the platform's float layout is not IEEE, and there is no corresponding C type whose layout could be in question. For the same reason a special value is returned rather than raised — the error the wider types report only arises on a platform that cannot represent it, which does not apply here. This matches CPython's own PyFloat_Unpack2, which also returns inf/NaN.

test_nd_array asserted the bit pattern rather than the value — bjdloadb(bjddumpb(np.float16(2.2))) == 16486 — while the float32 assertion on the following line compares against np.float32(2.2). It now compares against the value too.

Verified with the C extension enabled and disabled: the full suite passes (504 tests), and 0.0, -0.0, ±1.0, 20.0, 25.0, ±65504.0, the smallest normal and subnormal, ±inf and NaN all round-trip against struct.unpack('<e').

Found by a BJData writer that emits h for reals that are exactly representable as a half, which is legal per the spec but something no encoder here produces — dumpb writes d or D — so nothing exercised the scalar read path.