Add support for nan

[ajberdy]

Add support for nan-values.

Expected behavior:
oqpy.FloatVar(math.nan, "nan_var") -> float[64] nan_var = nan;

Observed behavior (pre-fix):

File "oqpy/oqpy/base.py", line 579, in detect_and_convert_constants
    rx = round(x)
         ^^^^^^^^
ValueError: cannot convert float NaN to integer

[braised-babbage]

Just FYI, the OpenQASM spec doesn't really have much to say about these values. The is no way to specify a NaN literal (or +- infinity either). The reference parser will just parse these as identifiers (which would then be unresolved by a downstream consumer). But if I take the spirit of this MR as just basically smoothing off a rough edge where oqpy would balk at certain well-typed Python values, then I'm not my remarks about the OpenQASM spec need block it.

[ajberdy]

This PR adds consistent behavior for nan with how inf/-inf are already handled.

In the OpenQASM spec, in the casting from float section, it says, "Casting the floating-point values inf, -inf and all representations of NaN to angle[m] is not defined."

In the complex numbers section, the spec says, "These operations use the floating-point semantics of the underlying component floating-point types, including their NaN propagation, and hardware-dependent rounding mode and subnormal handling."

Together, these seem to imply that OpenQASM leaves the door open for some level of inf/nan support depending on the hardware. In any case, I agree that the spirit of this MR is mostly to make sure oqpy isn't the missing link here.

[PhilReinhold]

This looks good to me. Let's just bump the patch version so we can do a release straight away.

[PhilReinhold]

LGTM