Update RPM build for Ci autoversion packages

[brianjmurrell]

Changes
Update .copr/Makefile's srpm target to run the last-minute bump_version before building the SRPM.

As much as I disagree with this approach and think that bump_version should be run and then the result of it committed so that the source tree has accurate and transparent versioning, if this approach of last-minute updating is going to go forward (against my advise) then this PR is how to make Copr build an RPM properly versioned.

This PR really should be based on https://github.com/joshuaboniface/jellyfin/tree/ci-autoversion-packages but for whatever reason, joshuaboniface is not showing up in the base repository selector. As such this PR includes all of the code from #6974. If somebody who can, wants to rebase this on #6974 and land it to there, that is fine. Or this can wait for #6974 to land and then it can be rebased on master and then landed to there.

[joshuaboniface]

If this is the correct way to do it, it's good by me. It's worth mentioning that this should only matter during these particular pre-release builds. "Real" versions will always have the results of bump_version committed.

[brianjmurrell]

If this is the correct way to do it, it's good by me.

Well, it is the way to have your concept of last-minute updating of versions prior to build to work in Copr. To be completely honest, this was just a build upon #6974 and should have only either landed into that PR or after it had approval and landing. Moreover, I was hoping to continue the conversation on why not committing pre-release build information into the source was not a good thing.

It's worth mentioning that this should only matter during these particular pre-release builds.

Yes, completely understood.

"Real" versions will always have the results of bump_version committed.

But IMO, the pre-release builds deserve as much transparency as "real" versions. If "real" versions are going to have the bump_version results committed, why not these pre-release builds also? Again, in the spirit of full transparency. And also to facilitate the folks that want to install the successive alpha/betas onto their testbeds to help test and report issues. Without committing the prerelease info (or I suppose this PR) into the source, successive build and updates won't happen on those users' systems. Indeed they won't even get updated from alpha1 to GA since the version doesn't actually change (without this PR or better yet, committing the bump_version results for pre-releases).

[brianjmurrell]

It's worth noting the addition of the make -f fedora/Makefile rpms target that actually builds the RPM in a "clean room" environment to provide the cleanest environment to build the RPMs in. TARGET can be set to any mock target such as epel-8-x86_64, fedora-<version>-x86_64, etc. This might be a good target for the RPM building CI recipes. Maybe I can see what I can do about transitioning that in the future and migrating the builds of packages away from being done as root.

Given that all of this (i.e. package building/release-engineering/devops/CI) is actually what I do in my $day_job to pay my bills and I want to transition our package building to GitHub Actions in the near future, I can apply what I do there to this project. I have been investigating a number of different approaches to clean room building in GHA now. The current approach in this project is not bad, even though it does not use mock. But the building as root is the primary big bad thing that needs to be rectified.