`lljson.encode()` should not encode NaN as illegal `NaN` literal

[HaroldCindy]

Many JSON parsers support NaN literals, but JSON.parse() in JS environments does not. JSON.stringify([NaN]) returns [null], so just do that. lljson.slencode() is available for cases where we care about round-tripping.

[Martin-Pitt]

The ECMAScript specification is the official standard where JSON comes from to begin with. Since there are some similarities between Lua and JavaScript (e.g. prototypal, number primitive, etc), it probably matters more here given the context for special numbers: JSON.stringify

Finite numbers are stringified as if by calling ToString(number). NaN and Infinity regardless of sign are represented as the String value "null".

[Suzanna-Linn]

slencode()could use a tagged NaN, "!fNaN". sldecode()can already use it.

print(lljson.slencode(0/0))  -- > NaN

local n = lljson.sldecode('"!fNaN"')
print(n == n)  -- > false

This way it would be readable JSON for scripters developing external javascript applications adapted to the internal slencode format to work with SLua types.

[tapple]

> math.isnan(lljson.sldecode('"!fNaN"'))
true

[HaroldCindy]

As of #61 lljson.encode() now encodes these as null, same as JS' JSON.stringify(). In slencode() they get their identify preserved through encoding as "!fNaN".