fix: allow multiple whitespace between coordinate ordinates (OGC WKT)

[spokodev]

Bug

parse("POINT (1 2)") returns null while parse("POINT (1 2)") returns {type:'Point',coordinates:[1,2]}. Two or more spaces between the X and Y ordinates of a coordinate tuple break parsing, even though a single space and a tab both parse fine:

parse('POINT (1 2)');   // {type:'Point',coordinates:[1,2]}   ok (single space)
parse('POINT (1\t2)');  // {type:'Point',coordinates:[1,2]}   ok (tab)
parse('POINT (1  2)');  // null                               BUG (two spaces)

It affects every geometry type that uses coordinate tuples:

LINESTRING (1  2, 3  4)          -> null   (expected [[1,2],[3,4]])
POLYGON ((0 0, 1  0, 1 1, 0 0))  -> null
MULTIPOINT (1  2, 3  4)          -> null

Spec

Under the OGC Simple Features WKT grammar the separator between ordinates inside a coordinate tuple is one or more whitespace, so 1 2, 1 2 and 1\t2 all denote the same point. Accepting the single-space and tab forms while rejecting the multi-space form is an internal inconsistency, and real-world WKT (PostGIS output, pretty-printers, hand-aligned columns) commonly pads ordinates with multiple spaces.

Root cause

Two spots assume exactly one whitespace between ordinates:

1. The tuples regex hard-codes a single \s, so on "1 2" it matches only "1" and the second ordinate is left unconsumed, then the closing ) check fails and parse returns null.
2. The ordinate splitters in coords() and multicoords() use split(/\s/g), so "1 2".split(/\s/g) yields ["1","","2"] and parseFloat("") is NaN. Widening only the regex would inject a spurious null ordinate, so both need fixing together.

Fix

Widen the tuples regex separator to \s+ and the four ordinate splitters in coords() / multicoords() from split(/\s/g) to split(/\s+/g). The bundled wellknown.js is updated to match index.js.

Tests

Added assertions that double-spaced POINT, LINESTRING and POLYGON parse to the same GeoJSON as their single-spaced forms. They fail on master (return null) and pass with this change. The existing suite stays green (lint plus all prior assertions, including the single-space and tab cases and the stringify round-trip).

Note

This is the ordinate-separator whitespace (between the X and Y of a tuple). It is distinct from issues #33 and #36, which concern whitespace adjacent to the parentheses (a different code path).