Possible bug in version ranges for generating a release with --tags

## Background

> I originally started this issue for a feature request, but I see now that this might be a bug. I've updated the title to reflect this.

In our current setup, we utilize `master` only development, in which we deploy to different environments based on tags:

// Deploys to dev test
npm version 1.0.1-beta.x

// Deploys to acceptance test
npm version 1.0.1-rc.x

// Deploys to production
npm version 1.0.1

This results with the usage of `gren` that only the `1.0.1-beta.x` contains the full release notes since last release, and not `1.0.1`.

Is it possible to have a feature that enables `gren` to concatenate, or use the preferred release notes for a tag? For example:

gren release --prerelease --override --tags=v1.2.0..v1.2.0-beta.0

## Conclusion
I see that this might be a potential bug, as `gren` is probably not accepting version ranges in tags correctly, specifically, between prereleases?

## Another relevant scenario

Old production release is `0.58.1`, I have a `1.2.0-rc.0` version not in production yet.

gren release --override --tags=v1.2.0..v0.58.1

This will populate release notes with ALL the commits and tags created historically between those tags, including tags like `1.3.0-beta.0` 🤦‍♂️

No source files or tests are named. Start by reproducing the two reported gren release commands with the stated tag ranges, then trace the tag-range handling and existing release-generation tests. Done means prerelease and production ranges select the intended commits and exclude unrelated historical tags.

Written by the indexing model from the issue text.