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` 🤦‍♂️

Nenhum arquivo-fonte ou teste é nomeado. Comece reproduzindo os dois comandos de release do gren relatados com os intervalos de tags indicados e, em seguida, rastreie o tratamento dos intervalos de tags e os testes existentes de geração de releases. O trabalho estará concluído quando os intervalos de prerelease e produção selecionarem os commits pretendidos e excluírem tags históricas não relacionadas.

Escrita pelo modelo de indexação a partir do texto da issue.