Extend generator filtering to support element ranges

[horenmar]

Note that all the ideas here are fully backwards compatible, so the
extension can be implemented without a breaking change

The recently-added generator filtering only allows filtering to a singular
element. This can be extended to support multiple elements and/or element
ranges.

For multiple separate elements, we can reuse the concept of commas as "OR"
from the test specs. This would then mean that -g 1,3,4 filters the
generator to indices 1, 3, and 4. For element ranges, we can use
the start-end format, so that -g 1-4 would filter the generator to
indices 1, 2, 3, and 4.

These two should also be combinable, so that -g 1,3,6-10 filters the
generator to indices 1, 3, 6, 7, ..., 10.

Examples

Accepted

• -g 1,2 - Elements at indices 1 and 2.
• -g 1-3 - Elements at indices 1, 2, and 3.
• -g 1-1 - Single element range, only the element at index 1.
• -g 1-3,4,5-10 - Elements at indices 1,...,10.

Rejected

• -g 1-3,2-4 - The two element ranges are overlapping
• -g 3,2,1 - Elements are in bad order, must be monotonically increasing
• -g 3-1 - Range is decreasing, see above
• -g 1,2,2,3 - 3rd element is duplicated
• -g -2 - Negative number, should still be rejected
• -g 1--2 - Syntactically invalid
• -g 1-2-3 - Syntactically invalid

Design questions

• Should the ranges be closed? Programming usually uses half-open ranges,
  but closed-ranges feel more intuitive for specifying the range on the
  command line.

• Should we error out on bad-but-fixable filters? Erroring out is less
  confusing, but fixing can be more user friendly.

  • Duplicated indices can be deduplicated.
  • Unsorted indices can be sorted
  • Overlapping ranges could be merged

• Should we support partially-specified ranges?

  • 3-* could mean "From 4th element to the end of the generator"