Fix quadratic parsing of leading whitespace

[theRizwan]

Fixes #49.

parse() was quadratic in the length of a leading whitespace run, so a long run of spaces blocked
the event loop for seconds.

input	before	after
8,000 spaces	231 ms	0.16 ms
16,000 spaces	924 ms	0.37 ms
32,000 spaces	~3,700 ms	0.63 ms

Before: ~4× per doubling. After: ~2×.

Cause

geckoRe and javaScriptCoreRe began with ^\s* followed immediately by a group that also matches
whitespace — (.*?) and ([^@]*). A leading run of spaces could be divided between the two in n
ways, and a non-matching line forced the engine through every split.

chromeRe, winjsRe and nodeRe are untouched: each has a literal at right after ^\s*, which
anchors the boundary and prevents the ambiguity.

Why it is worth fixing

err.stack embeds the message, so attacker-influenced text reaches the parser directly:

const err = new Error('Invalid value: \n' + ' '.repeat(30000));
parse(err.stack);   // ~3.3s of blocked event loop

Availability only — nothing is disclosed or corrupted — but a single request can stall a service
that parses stack traces from errors carrying user-supplied values.

The change

Dropping the leading \s* is what makes the match linear. It was doing one useful thing, keeping
leading whitespace out of the captured methodName, so that moved to where the capture is read:

methodName: (parts[1] && parts[1].trim()) || UNKNOWN_FUNCTION,

Behaviour is unchanged — including the UNKNOWN_FUNCTION fallback, since an all-whitespace capture
now trims to '', which is still falsy.

I checked this rather than assumed it: removing ^\s* alone broke parses JavaScriptCore errors,
which expects methodName: '_exampleFunction' and was getting ' _exampleFunction'. The trim
is what keeps that fixture green.

Tests

All 35 existing fixtures pass unchanged, and one timing test added.

Confirmed it catches the regression — on current main the suite reports 35 passing, 1 failing
and takes 4 seconds; with the fix, 36 passing in 17 ms.

The threshold is deliberately loose (8× headroom plus 100 ms) so it will not flake on a slow or noisy
CI machine, while still failing decisively on the quadratic behaviour, which is ~16× for the same
input growth.