🐛 Fix the logic that determines previous git tag

[huutomerkki]

What this PR does / why we need it:

This PR changes the way previous tag is determined to only include those tags that have been merged into the current tree.

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign elfosardo for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tuminoid]

Technically the right change, but practically not working. For example, we don't have v0.6.0 tag in main at all, nor we have v0.8.0, so if we check what the command now picks for v0.9.0, it'll compare it to v0.5.0.

Issue here is that when we make minor RC releases, they're already made from release branches. Thus the tags do not appear in main, and are not considered when making next minor. In release branches this logic works, but so does the old one.

[tuminoid]

Also, metal3-io/ip-address-manager#734 in IPAM will change the release creation logic, and will implement the same in Go code, so it makes no sense to implement this here.