Use meaningful type aliases for points and ranges

[TedDriggs]

Throughout the code usize is used for line numbers, column numbers, tuple indexes, and source points. For a new contributor, this makes it harder to read the code and be confident in what's happening.

• core::Point is an alias for usize when it's used as a source position.
• core::SourceRange is an alias for (usize, usize) when that is a range in source text.

This PR uses type aliases rather than newtypes to avoid any perf or compatibility risks. Replacements were made by hand to ensure that usize was still used when not referring to a point.

[jwilm]

This PR uses type aliases rather than newtypes to avoid any perf or compatibility risks.

Newtypes shouldn't have any perf issues. I use them pretty extensively in Alacritty without issue. Compatibility, on the other hand, it a bit more challenging. For a simple usize newtype, it can be helpful to implement a bunch of ops for that newtype. Although, there may be crates that provide something like #[derive(Newtype)] for simple math ops.

SourceRange feels a bit funny here: is it bytes or chars? I know the answer, but the type name doesn't demonstrate it. Since we're on the subject of (usize, usize), I would also suggest that it be changed to Range<usize>.

Although better than simple usize, type aliases don't add much beyond readability improvements. What do you think about looking into the newtype approach plus swapping (usize, usize) for Range<usize>? I'd be ok accepting this PR as-is and making that change in a follow-up patch.

[TedDriggs]

I'd be fine moving to Range<ByteOffset> with either pub struct ByteOffset(usize) or pub type ByteOffset = usize;. I think the former would be a breaking change though; the Match type includes a public point property.

Update: I started making the Range change, but at the moment it's not doing the readability many favors. It looks like rust-lang/rust#37854 will help with the readability of this quite a bit. In the meantime, how about I just rename SourceRange to SourceByteRange and punt on any meaningful type changes for the moment?

[jwilm]

how about I just rename SourceRange to SourceByteRange and punt on any meaningful type changes for the moment?

Works for me. Would you mind filing an issue for the type changes? We can always keep the public API stable while cleaning up internals.