fix: support ISO 8601 date, date-time, and 24-hour ranges

[Hussein-Abdallah]

What problem is this PR solving?

liqe only supports numeric range queries (e.g. height:[100 TO 200]). Any non-numeric boundary fails — an ISO date such as created:[2020-01-01 TO 2020-12-31] throws a SyntaxError at parse time, and quoted string boundaries are rejected too.

This PR adds range support for ISO 8601 dates, UTC date-times, and 24-hour times, so queries like these filter correctly (inclusive [ ] and exclusive { } both supported):

created:["2020-01-01" TO "2020-12-31"]
created:["2020-01-01T00:00:00.000Z" TO "2021-01-01T00:00:00.000Z"]
startTime:["09:00" TO "17:00"]

Quoted boundaries are compared lexically. Only canonical, big-endian formats are accepted — that is the condition under which lexical ordering equals chronological ordering — so any other boundary (free text, DD-MM-YYYY, timezone offsets, lowercase z, or mismatched precision) throws a TypeError, consistent with liqe's existing Expected a number. value error. Numeric ranges and structural SyntaxErrors are unchanged.

Related to #3 and #8: date and date-time filtering is now possible via ranges; the :>= / :<= comparison operators shown in #8 are a planned follow-up.

What is the impact of this PR?

End users: can now filter by date / date-time / time ranges using the existing range syntax, with the boundaries quoted.

Developers / behaviour change: a string range whose boundaries are not a supported, consistent format now throws a TypeError at filter time (previously such input either failed to parse or matched nothing). Numeric ranges are unaffected, and there is no change to the public API surface (the new validation is internal).

Data requirement: lexical comparison equals chronological comparison only for canonical values — single-timezone UTC (Z), fixed width, big-endian ISO. Non-canonical inputs (12-hour times, DD-MM-YYYY, local offsets) must be normalised before querying.