Shave a bit more performance

[Arkham]

Methodology

Bench corpus is ~/.elm/0.19.1/packages/ — 235 files, ~2.85 MB of Elm
source — using a Node harness that loads four ParserFast workers
side-by-side: plain master (baseline), master + commit 1,
master + commit 2, and master + both (this PR's HEAD). Each worker is
the same ParseMain.elm modified to NOT JSON-encode the AST so the
timing window only measures Elm.Parser.parseToFile itself, with no
contention between parse and encode for V8 tier-up budget.

Each worker runs over the corpus 40 times after 5 warmup iterations. The
table below shows median of 6 separate full bench runs to dampen
thermal/scheduler noise.

Per-iteration ratios are also reported because they are
thermal-noise-immune: each ratio uses a (variant + master) pair measured
in the same OS state, so when the CPU got hot they slowed down together.

Per-commit results vs master HEAD

	min (ms)	median (ms)	speedup vs master	per-iter ratio
master (baseline)	103-108	105-112	—	1.000
master + commit 1	100-104	103-106	~2-3%	0.94-0.99 (median 0.97)
master + commit 2	102-103	104-106	~1-3%	0.94-1.00 (median 0.98)
master + both (HEAD)	98-99	100-103	~4-6%	0.91-0.96 (median 0.95)

What changed

Commit 1 — Layout: peek 1 char before paying for 2-char comment-start check
(src/Elm/Parser/Layout.elm)

whitespaceAndCommentsOrEmpty runs between every pair of tokens — easily
the hottest path in the parser. The previous code unconditionally sliced 2
chars and ran a multi-string case over them, even though the vast
majority of calls land in the no-comment branch. Replaced with a 1-char
slice + nested 1-char check, so the common path now allocates one less
substring per call.

Commit 2 — Force === for Int compares + empty-consume short-circuit
(src/ParserFast.elm, src/Elm/Parser/Expression.elm)

The Elm compiler only emits JS === for ==//= on Int when one side
is a literal integer. When both sides are computed (e.g.
charCode /= openCharCode, or newOffset == -1 — which is parsed as
Basics.negate 1, not a literal), it falls back to _Utils_eq, whose
outer loop allocates a stack = [] array on every call. This adds up
fast inside per-character parser loops.

Replaced a == b with a - b == 0 (and similar) at every site where the
compiled JS was emitting _Utils_eq on Ints:

• isNotRelevant in the multi-line comment body scanner
• infix non-associative precedence check in Expression.elm
• anyChar / anyCharFollowedByWhileMap end-of-source markers (== -1, == -2)
• the empty-consume short-circuit in whileWithoutLinebreakAnd2PartUtf16ToResultAndThen

That last one — short-circuiting when zero chars were consumed — is folded
in here because it's structurally tied to the same parser. It fires after
every expression not followed by an infix operator (the common case) and
skips an empty-string String.slice + callback dispatch + Bad /
ExpectingCustom allocation. On its own it was within noise; combined
with the Int-compare trick at the same call site it becomes part of a
clear measurable improvement.

Net result in the optimized JS: 9 distinct _Utils_eq call sites → 3
(only string comparisons in declaration-vs-signature name matching
remain — those can't easily use the same trick).

Tests / regressions

• elm-test: 522/522 pass on each commit independently
• node find-regressions src/: no AST regressions

[lue-bird]

Awesome! I think there are also still some ++ ""s remaining in some equality checks if you want to add them to this PR for a few more percents