perf: lightweight TextSpan for tokens (LocationSpan only for diagnostics)

[AlternativeLua]

Summary

Continues the recent lexer perf series (number/string/operator lexing): tokens now carry a lightweight TextSpan — just Position + Length — plus a SourceFile reference, instead of a full LocationSpan. Line/character resolution (binary search over line starts) is deferred to Token.GetLocation(), which is only invoked on diagnostic paths.

Changes

• New TextSpan struct (Loom.Core/Text/TextSpan.cs): position + length with value equality; no file reference, no line/char computation.
• Token stores TextSpan Span + SourceFile File; GetLocation() materializes a LocationSpan on demand. A LocationSpan-based convenience constructor keeps synthetic-token call sites (TokenFactory, tests) unchanged.
• Lexer tracks plain int positions through the hot loop — Location/LocationSpan structs are now only constructed inside diagnostic reporting (GetSpan).
• Keyword lookup uses Dictionary.GetAlternateLookup<ReadOnlySpan<char>>, eliminating the per-identifier substring allocation previously needed for the KeywordMap probe.
• Token record equality now compares two ints instead of LocationSpans, whose Location.Equals computed line/character lazily via binary search.
• Consumers that treated a token span as a location (DiagnosticBag token overloads, parser paren-mismatch messages, TypeSolver.CheckCircular, Node.DeriveSpan, function-signature validation) go through GetLocation().
• Dropped the now-unused LocationSpan.operator+.

Node.Span remains a LocationSpan; its construction from token locations stays lazy, so no line computation happens at node-construction time. AST/Luau snapshots are unchanged.

Testing

• dotnet build clean
• dotnet test: 1693 passed, 0 failed

🤖 Generated with Claude Code