Fix literal expression position off-by-two errors

[nawforce]

Summary

Fix off-by-two position errors when reporting literal expressions in the outline parser.

Background

The outline parser currently reports literal expression positions that are 2 characters earlier than expected, compared to the ANTLR parser. This affects 3 test failures in apex-dev-tools/apex-ls#434.

Example from failing tests:

"public class Dummy { Object a = 12345678901; }"
// Literal "12345678901" is at character positions 32-42
// ANTLR expects: "line 1 at 32-43"
// Outline parser: "line 1 at 30-41" (both start and end are 2 positions too early)

Test failures:

• LiteralTypeTest - "Oversize Decimal": expected 32-83, got 30-81
• LiteralTypeTest - "Oversize Integer": expected 32-43, got 30-41
• LiteralTypeTest - "Oversize Long": expected 32-53, got 30-51

Investigation Needed

The exact cause needs to be identified, but likely locations include:

1. Literal token capture in OutlineParser.scala

   • Check how numeric literals are being tokenized
   • Verify position tracking during literal consumption

2. Expression/literal CST construction

   • Could be in apex-ls's integration code when constructing expressions from outline parser tokens
   • Or in outline-parser's literal handling

3. Position offset calculations

   • The consistent off-by-2 suggests a systematic offset error
   • May be related to how byte offsets vs character offsets are calculated

Success Criteria

After the fix:

• Run apex-ls test: sbt apexlsJVM/testOnly *LiteralTypeTest
• All 3 literal position tests should pass
• Positions should match ANTLR parser output exactly

Related Issues

• Outline parser diagnostic positions inconsistent with ANTLR parser apex-ls#434 - Outline parser diagnostic positions inconsistent with ANTLR parser (Category C)

Notes

This issue is independent of #19 (modifier/annotation locations) and can be worked on in parallel once the root cause is identified.

[nawforce]

This issue was resolved by PR #24.

The off-by-two position error for literal expressions was fixed by two systematic changes to position tracking:

1. Changed lineOffset from 1-based to 0-based indexing - This fixed 1 character of the offset error
2. Made end positions exclusive - Added +1 to endLineOffset and endByteOffset in Buffer.captured(), fixing the other character of offset

These changes affected all position tracking (not just modifiers/annotations), including literal expressions.

From the PR #24 commit message:

Changed lineOffset from 1-based to 0-based indexing to match ANTLR conventions
Made end positions exclusive ([start, end) half-open interval) for both columns and byte offsets
All 6,303 tests pass successfully with location tracking fully enabled.