refactor(parser): implement NthToken for T

[denbezrukov]

Summary

We have code duplication around the non-trivia lookahead in our parser. The MR attempts to extract the common parts into the parser crate. Basically, we have a non_trivia_lookahead vector for each token source. We can try to move them inside the current lookahead in the buffered lexer, because we are interested only in non-trivia lookahead.

Test Plan

cargo test

[github-actions]

Parser conformance results on

js/262

Test result	main count	This PR count	Difference
Total	49701	49701	0
Passed	48721	48721	0
Failed	980	980	0
Panics	0	0	0
Coverage	98.03%	98.03%	0.00%

jsx/babel

Test result	main count	This PR count	Difference
Total	40	40	0
Passed	37	37	0
Failed	3	3	0
Panics	0	0	0
Coverage	92.50%	92.50%	0.00%

symbols/microsoft

Test result	main count	This PR count	Difference
Total	6322	6322	0
Passed	2036	2036	0
Failed	4286	4286	0
Panics	0	0	0
Coverage	32.20%	32.20%	0.00%

ts/babel

Test result	main count	This PR count	Difference
Total	662	662	0
Passed	593	593	0
Failed	69	69	0
Panics	0	0	0
Coverage	89.58%	89.58%	0.00%

ts/microsoft

Test result	main count	This PR count	Difference
Total	17646	17646	0
Passed	13439	13439	0
Failed	4205	4205	0
Panics	2	2	0
Coverage	76.16%	76.16%	0.00%

[codspeed-hq]

CodSpeed Performance Report

Merging #2727 will not alter performance

_{Comparing chore/nth (1d55e30) with main (c269016)}

Summary

✅ 85 untouched benchmarks

[ematipico]

Oh, you managed to kill the lifetime! (To reduce it during lexing)

I did try to do that some time ago but then stopped.

Great refactor! Is there some documentation (contribution guide) we need to update?

[ematipico]

Why 5?

[denbezrukov]

Oh,
I wanted to look at the performance tests, but it seems there is no effect,
Do you think it's better to use just new?
5 is a the longest lookahed

[ematipico]

Yeah, if there's no change in performance, maybe we should stick to new