Greedy computation of spans

[uncomputable]

The current parser greedily computes spans of each part of the source. This operation is O(n) in the size of the source text and potentially slow. This bug was introduced in #34 (oops). Can we speed up the parser?

[stringhandler]

Not sure if this is still relevant after #185. Perhaps we can close?

[KyrylR]

Will retest this as well

[KyrylR]

I retested this on current master and did not reproduce the original regression

The current code path already avoids the old behavior: spans are produced once in the lexer in src/lexer.rs#L221, carried through parsing in src/parse.rs#L892, and line/column lookup only happens when formatting an error in src/error.rs#L215

That matches the retest results: parse time scaled roughly linearly up to a generated input of about 111 KB

Measured parser-only timings on generated valid input:

• 100 functions, 2617 bytes: 7.8 ms
• 500 functions, 13417 bytes: 29.6 ms
• 1000 functions, 26917 bytes: 57.8 ms
• 2000 functions, 54917 bytes: 112.5 ms
• 4000 functions, 110917 bytes: 226.1 ms

So this looks fixed on current master, though it may still be worth adding a parser performance benchmark to guard against regressions