Parser: reduce substring + java.time allocation churn in numeric/timestamp parsing

Summary

After regex matching, the next biggest allocation source in the parser is temporary String / byte[] and java.time objects created while parsing numeric and timestamp fields. Each parsed line slices substrings and builds intermediate java.time objects that are immediately discarded.

Evidence (JFR settings=profile, ~28s run)

Workload: sample Main parsing a 195 MB JDK8 ParallelGC rolling log (gclogs/rolling/jdk8/aagl_prd/gc.log), -Xmx1500m, G1, Java 25 (GraalVM 25.0.3). ~19,985 MB sampled allocations.

Allocation by site:

Allocation by class (related): byte[] 7.98%, java.lang.String 3.30%, java.time.format.Parsed 2.61%, LocalDateTime 2.05%, LocalDate 1.87%, LocalTime 1.56%.

Suggested fixes

• Parse numerics directly off the matched region using index offsets rather than substring(...) + Double.parseDouble(...) (avoids String + byte[] + FloatingDecimal churn).
• Avoid building intermediate java.time objects on the hot path; reuse a preconfigured DateTimeFormatter and resolve straight to an epoch value. DateTimeStamp.dateFromString and AbstractLogTrace.convertToDouble are good entry points.

Expected impact

Reduces ~15–20% of sampled allocation pressure (substring + java.time + FloatingDecimal). Complements the Matcher-reuse work; GC is already healthy (98.76% throughput) so this improves allocation throughput / CPU, not pauses.

Start with AbstractLogTrace.convertToDouble(String) and DateTimeStamp.dateFromString(String), then trace their callers in the numeric and timestamp parsing paths. Compare the current substring and java.time allocation behavior with the matched-region and formatter approaches described in the issue. Done means parsing behavior is preserved while the supplied JFR workload shows lower allocation pressure.