Support specifying a range of versions in deny-packages

[ellenfieldn]

Is your feature request related to a problem? Please describe.
Recently, I've run into a scenario where I want to prevent consuming versions of a package newer than x.0.0 (specifically, FluentAssertions switching to a commercial license for anyone interested).

In this case, the License is unknown, so I have to rely on blocking the undesired versions of the package itself.

Describe the solution you'd like
I would like an easy way to specify one or more ranges of package versions to deny. Some examples in plain English (though my brain seems to have really latched onto semantic versioning 🤷 ):

• Deny all versions of 'X' greater than 8.0.0
• Deny all versions of 'X' before 4.6.2
• Deny all versions of 'X' between 2.5.0 and 2.6.7

For the purpose of denying packages, features like using ^4.0.0 to indicate 4.x.x or ~4.0.0 to indicate 4.0.x aren't particularly important to me. Additionally, I don't need the ability to treat versions such as 5.0.0-pre1 or 5.0.0-alpha distinctly from 5.0.0, but I could see how others might want that ability.

Describe alternatives you've considered

• I could explicitly add each new version to the deny-packages list as they are released. This would be time consuming to keep up with. There would also be risk that changes are merged before we are able to update the list.
• Open source versions of the package are used frequently enough, that removing it would be pretty time consuming. Even with this approach, having a way to not accidentally use the wrong versions in the meantime would be helpful.

My current short-term approach is to:

• Maintain a fork of this repo and apply a naive version matching approach. I just used the semver npm package so that I can specify something like pkg:nuget/FluentAssertions@>=8.0.0 to block 8.0.0 and all subsequent versions of the package.
• I'm focused on a pretty narrow set of ecosystems, so this approach happens to meet my needs. However, this likely wouldn't support the full variety of versioning formats used across the set of purl types -- could it potentially lead to confusing and incorrect behavior in certain ecosystems/types? Honestly, I don't know.

Additional context
I saw prior some discussion in #705. It sounds like this functionality was previously deferred based on the status of https://github.com/package-url/purl-spec/blob/master/VERSION-RANGE-SPEC.rst as well as the bandwidth required to implement it.

edit: I'm also willing to help in any way that I can.