Fine tune slice range to fix #170

[glromeo]

@bcoe I isolated in this PR the fix for #170

In the PR #172 I implemented

v8-to-istanbul/lib/range.js

Lines 26 to 28 in 1f357fa

	while (end < lines.length && extStartCol < lines[end].endCol && endCol >= lines[end].startCol) {
	++end
	}

with a conservative mindset leaving the endCol >= lines.startCol that was originally in

v8-to-istanbul/lib/source.js

Lines 78 to 81 in 53c1cd8

	const lines = this.lines.filter((line, i) => {
	return startCol <= line.endCol && endCol >= line.startCol
	})
	if (!lines.length) return {}

and this >= is the cause of #170

This PR aims at fixing #170 with the least side effects as possible.

C8 is fine

The changes in the snapshot reflect the end of the range being exclusive (https://v8.dev/blog/javascript-code-coverage)

while 538 corresponds to 37:0 so line 37 cannot be taken in the range

[bcoe]

@glromeo this looks reasonable to me, because the line ranges are so finicky, I will probably still test on a few other codebases before merging ... if I recall the remapping step of applying source maps was most sensitive to small changes like this, I'd like to test against a few large TypeScript codebases.

[bcoe]

The column changing significantly concerns me a little bit, because I think it suggests we identified a different statement, this is where source maps can really start to behave drastically different.

A good TypeScript codebase to test on is this one:

https://github.com/googleapis/release-please

and this one:

https://github.com/yargs/yargs

[glromeo]

@bcoe sorry for taking so long...I needed a break to come back to this problem with a fresh mindset and I think I might indeed have a better idea of how to solve it.
I consider this a dead end because it coincidentally solves the problem of #170 by always going one mapping short which in the case of tsc where the mapping for } is actually present ends up being wrong!