Defensively detect SemVer prereleases when GitHub marks them as stable

[TyceHerrman]

Better Add-on Manager can currently treat a SemVer prerelease tag as stable when its GitHub Release is incorrectly published with prerelease: false.

For example, Obsidian Linter's 1.33.0-rc-1 release:

• has a SemVer prerelease suffix;
• is reported by the GitHub API as prerelease: false;
• is consequently labeled “Latest” by GitHub; and
• appears in BPM as “GitHub Latest” and “Stable,” even when prereleases are disabled.

#71 added prerelease filtering for GitHub releases. This issue covers malformed release metadata that lets SemVer prereleases bypass that filter.

Could BPM defensively treat a release as a prerelease when either:

• GitHub reports release.prerelease === true; or
• the release tag parses as SemVer with a prerelease component, including tags such as 1.33.0-rc-1, 1.33.0-rc.1, or 1.33.0-beta.1?

When prereleases are disabled, these releases should be excluded from update targets and should not be labeled “Stable,” even if the GitHub metadata is incorrect.