Avoid exceptions when parsing text conditions

[SupaYoshi]

Problem

Condition.parseValue(...) currently tries Integer.parseInt(...) and then Double.parseDouble(...) for every operand. Caught NumberFormatException is therefore the normal control-flow path for every text condition.

For example, evaluating full == full creates four caught exceptions: two numeric parse attempts for each of the two valid string operands. This is especially costly when conditions are refreshed frequently for online players.

A bounded 90-second JFR from a low-load Paper server recorded:

• 8,065 exceptions at NumberFormatException.forInputString(...);
• 8,035 exceptions at FloatingDecimal.check(...);
• 15,374 exception messages for full and 726 for compact.

That is 16,100 caught numeric parse exceptions in 90 seconds for ordinary string placeholder values. The raw production recording is intentionally not attached because it can contain server-specific runtime data.

Change

• Parse integers with a small bounds-checked digit loop, avoiding exceptions while preserving signs, integer limits, and Java's Unicode-digit behavior.
• Use one precompiled pattern to identify the remaining Java floating-point literals before calling Double.parseDouble(...).
• Treat all other values directly as booleans or strings.

This removes exceptions from the expected string path without changing condition syntax or operators.

Compatibility covered by tests

• text equality, inequality, contains, and startsWith, including full and compact;
• booleans;
• integer boundaries, Unicode digits, and values above the integer range;
• decimals and scientific notation;
• hexadecimal floating-point literals;
• numeric suffixes;
• Infinity and NaN semantics.

The full Maven reactor build passes on current master with all tests green.

I also applied the same source change locally to the exact v1.5.8 tag. A local JFR-backed test evaluated 200,000 text conditions and recorded zero Condition.parseValue / numeric parsing exception signatures. Nothing from this RealScoreboard patch was deployed to the production server.

Scope

• no scoreboard layout or rendering change;
• no PlaceholderAPI integration change;
• no condition operator change;
• no configuration or data-format change.

[neziw]

looks fine for me

[joserodpt]

seems good, approved. thanks!