Optional query for GitHub releases to make badge yellow if not using latest

[andrewg-xyz]

:clipboard: Description

Add a parameter to compare the specified release against the latest release and change the badge color if the release is not the latest.

For Example:

https://img.shields.io/github/v/release/defenseunicorns/zarf?filter=v0.28.0&label=using%20Zarf&compare=latest

The badge would be yellow when there is a newer release available

[jNullj]

I think i can add this, assign me if you want me to work on it.

[calebcartwright]

Appreciate your willingness to jump in @jNullj!

I suspect this one probably warrants some discussion first though (e.g. is this something that would be better suited to a [Custom Endpoint badge](https://shields.io/badges/endpoint-badge?, if we do add it directly should it be scoped to GitHub releases or extended to other GitHub badges or even beyond?, should the color always be yellow or should that be customizable too?, etc.)

FWIW my initial reaction is that this is better deferred to an Endpoint badge, but curious what others think

[jNullj]

Here is some things i think we could consider:

Pro: This is informative and visually and clearly indicate versions currentness Pro: Increase customizability, users can use it if they want the option

Con: This will require more API calls and caches Con: We might have to call APIs that differ from the main API used by the shield, for example we might need to call NPM to check versions for a Github repo. Con: Makes those shields more complex

Info: We might need to set which part of the semver we want to mark as outdated (major, minor), if we pick it hardcoded it will be less flexable but will communicate status in a similar way across shields ,on the other hand, if we let the user pick the version level it gives more flexability, we could also use version operators (like npm allow in pacakge.json to decide on version level to check).

If we do it for this badge there is no reason to not to add this to all shields, we will have to make a list, this will probebly take some effort tho.

About Custom endpoints, I'm not sure when should a requested feature get a shield implementation and when we should use custom endpoint, Is there any guidelines to where we draw this line?