Feat: Use Git Tags for release number calculation & changelog processing

[LordAlfredo]

Rpmautospec has no way to know the actual release history and cannot verify its calculated releasenum and changelog match reality. By using git tags, we can add metadata to the git repo to hint the real release history, enabling Rpmautospec to correctly calculate the exact next release number (even if it's a rebuild!) and construct the changelog based on historical N-V-R data. By using tag namespaces, we can also support multiple build systems and OSes from the same git repos.

By default, Rpmautospec will continue to use existing behavior. The new git tag path will only be used if a tag namespace parameter is entered.

This includes a few pieces:

• autorelease now either takes previous matching N-V tag and bumps R, or resets if none match.
• autochangelog has a few options. Firstly, as multiple tags may exist on a given commit, it will either show the lowest tagged V-R (default) or highest. Secondly, there are two git tag operation modes. In tagged-only mode, the changelog is generated using only tagged commits by walking V-R history. In accumulation mode, tagged commits head changelog entries and intermediary untagged commits are grouped into the next release entry. On unresolvable merge, we simply jump to the next unprocessed tag (attributing in-line the same style as kernel releases).

I have tested this by e.g. tagging packages with unresolvable Rawhide merges, such as mesa, and comparing original behavior, tag-only, and accumulation mode. While I have not tested every package using Rpmautospec, thus far I have seen zero processing failures with tags. Within Amazon, this also solves our issues with merges from each upstream (not just from Fedora).

I have standardized handling of the namespaced format by extending behavior in -core

I have bumped minor version given this is new functionality/enhancement and to better delineate dependency versions across all Rpmautospec component packages.