Implement empty ranges RFC

[rhagenson]

Implement RFC-76: "Introduce Empty Ranges"

This commit additionally adds tests for known footguns. The additional tests are not detailed in the RFC.

Full RFC text is available at https://github.com/ponylang/rfcs/blob/main/text/0076-introduce%20empty%20ranges.md

Closes #4255

[rhagenson]

I found an instance of "footgunnery" in the "Examples of Affected Ranges" from the RFC

Range(0, 10, -1), .is_empty() == true, .is_infinite() == false

In actual Pony, this would be Range[A](0, 10, -1) where A is the type parameter. Well if A = USize then Range[USize](0, 10, -1) which wraps around to be Range[USize](0, 10, 18446744073709551615) which is not empty, nor infinite, but rather produces a single element of [0] -- this applies to all unsigned integers. Of course, then A is a float or signed, then the above does apply. I added additional tests to cover this.

[SeanTAllen]

@rhagenson that footgun was discussed on the RFC and was decided that it wouldn't be address at this time. That was left to a further RFC to sort out.

[rhagenson]

I do not doubt it was discussed. Only instance from the list of affected ranges that I have found so far as being not quite the same based on the type parameter used so making the entry in the list misleading. I added tests and will need to note it in the docs that it is a possible tripping point.

[ponylang-main]

Hi @rhagenson,

The changelog - changed label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do.

Release notes are added by creating a uniquely named file in the .release-notes directory. We suggest you call the file 4280.md to match the number of this pull request.

The basic format of the release notes (using markdown) should be:

## Title

End user description of changes, why it's important,
problems it solves etc.

If a breaking change, make sure to include 1 or more
examples what code would look like prior to this change
and how to update it to work after this change.

Thanks.

[rhagenson]

I believe I have covered everything from the RFC. I added to the original scope only in additional tests and one sentence in the proposed docstring to note the wraparound when using an unsigned type and negative literal. I organized tests by the three classifications (finite, infinite, and empty) as well as removed an unused testing function (_count_range).

[SeanTAllen]

I don't think it is important that this came through the RFC process at least as part of the release notes. If you can bring more information about what changed into the release notes, that would be good with perhaps an "additional information available here" type link to the text of the RFC.

[SeanTAllen]

I don't think this paragraph will mean anything to someone who hasn't read the RFC.

I'd like to see a large portion of the motivation section from the RFC written to the past tense and included as the bulk of the release notes to explain why a change was made and then the additional expansion of examples as noted below.

[rhagenson]

I took a crack at rewriting to keep it short, but increase the amount of "why we made the change" included in the release notes. Take a look when you can and tell me what you think. I was struggling with how to not simply repeat the entire motivation section with all its additional details that would, in my opinion, lead to as much old/outdated code as new/working code without very clear delineation.

[SeanTAllen]

@rhagenson can you update the first comment to be the commit comment that should be used when squashing and merging this PR?