Extend generator filtering to support element ranges

_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"