Fix float parsing precision in SimpleQueryParser

[abdelaziz-mahdy]

Problem

SimpleQueryParser corrupted small float values (e.g., 0.001, 0.0001) during parsing. The digits grammar action applied parseInt() to the fractional part of floats, stripping leading zeros — 0.001 became 0.1, 0.0001 became 0.1. This broke all float-based queries (IN RANGE, equality, comparison) for values with leading zeros after the decimal point.

Separately, Constant.toMQL() used toFixed(20) which added floating-point noise to the output (e.g., 0.1 became 0.10000000000000000555).

Solution

Add a rawDigits grammar symbol (identical grammar to digits but without the parseInt action) and use it in the float rule. This preserves the raw digit string "001" during float parsing instead of converting it to 1. Fix applied to both JS and Java parsers.

Fix Constant.toMQL() to use String() (shortest exact decimal representation) with toFixed(20) fallback only for scientific notation.

Changes

• Add rawDigits grammar symbol in both JS and Java SimpleQueryParser to preserve leading zeros in float fractional parts
• Fix Constant.toMQL() float formatting: String() instead of toFixed(20) to avoid floating-point noise
• Add small-float precision tests to SimpleQueryParserTest, SimpleQueryParserJavaTest, and SimpleQueryParserMQLTest

[VesnaSUG]

@abdelaziz-mahdy why are we duplicating the grammar here. Shouldn't we have digits just call sym(rawDigits)?

[abdelaziz-mahdy]

noted: fixed

[kgrgreer]

The Java version has the same issue:
g.addSymbol("float",
new Seq1(1,
g.sym("ws"),
new Join(new Seq(
new Optional(Literal.create("-")),
g.sym("digits"),
new Optional(new Join(new Seq(Literal.create("."), new Optional(g.sym("digits")))))))));

[abdelaziz-mahdy]

The Java version has the same issue: g.addSymbol("float", new Seq1(1, g.sym("ws"), new Join(new Seq( new Optional(Literal.create("-")), g.sym("digits"), new Optional(new Join(new Seq(Literal.create("."), new Optional(g.sym("digits")))))))));

fixed.