coff: decode Base64 section-name offsets for large coverage objects

[honkstar1]

Summary

• Decode the LLVM/GNU extended COFF section-name format: // followed by a most-significant-first Base64 string-table offset.
• Keep normal inline names and decimal /offset references unchanged, and bounds-check indirect offsets before reading the string table.
• Add regression coverage for all Base64 digit classes, the seven-digit decimal boundary, offsets above 10 MB, malformed/out-of-range references, and inline names.

Problem

Large coverage-instrumented COFF objects can have string tables whose section-name offsets exceed 9,999,999. LLVM then emits names such as //AAyPM2 (offset 13,169,462) for .lcovfun$M. Interpreting this as a decimal reference produces bogus output-section names. The coverage records remain in the executable but are no longer discoverable by llvm-cov, resulting in function/profile mismatch warnings and incomplete reports.

This fixes section-name decoding rather than changing COMDAT selection, coverage instrumentation, or executable code generation. The change also applies to other long section names using this encoding.

Validation

• New regression crashes with the previous decoder and passes with the fix.
• Clean dev-based release build of radlink and torture; both COFF tests pass.
• Native two-translation-unit coverage fixture with Base64 section-name references beyond 10 MB: link, run, profile merge, and coverage report succeed without warnings.
• Combined downstream build: 15 targeted COFF/COMDAT tests pass, including the existing function-prefix regression; Oodle-compressed extended-name fixture passes end-to-end.
• Replayed a large x64 coverage target against the same existing profile: 635 mismatches before, zero after. Both HTML and text llvm-cov show commands succeed with empty stderr. Coverage function/region/line/branch totals match lld-link.

Based directly on dev; no dependency on the other open radlink PRs.

[NikitaSmith057]

manually merged in: 6380ab2