Remove dated RBF files for MiSTer

[jotego]

The MiSTer scheme for version control depends on a date attached to the file name. MiSTer selects the RBF name with the oldest timestamp to load.

Pros

• Users can easily go back to old versions and check when a problem was introduced

Cons

• The releases folder becomes cluttered with files (example)
• You cannot use git log or other tools to browse the commit history
• The flow is different from other platforms. MiSTer is the only one decorating the RBF name
• When testing old versions, you still have to manually delete the recent RBF in MiSTer, rather than just doing a copy with overwrite of the RBF
• If a newer version is discarded because of a problem and deleted from JTBIN, it is not clear whether update_all will delete that version from users' systems
• JTFRAME and JT cores have started using a conventional three-digit versioning system (like v1.0.0) which is displayed in the OSD about menu, rather than a timestamp or git commit. The core version should be the guide to select a file, not the timestamp.
• When cloning JTBIN you get all old versions, even if you would be happy with a shallow clone. The repository size is now over 1GB. Allowing shallow cloning would be good

Proposal

• Delete the time stamped RBF files and replace with a single RBF, e.g. jtcps1.rbf
• Modify jtcore so MiSTer compilations don't get the time stamp
• Modify update_all so it deletes time-stamped RBF cores and replace them with the regular jtcore.rbf as the release folders in JTBIN transition to the new system

Users would still be able to browse old versions, but either using GitHub or git's natural version browsing instead of simply picking up files in a folder by name.

@theypsilon what do you think?

[theypsilon]

I think having all previous binaries in version control is not the best practice, especially in a repository like jtbin, so I like the idea overall.

But it is nice that right now, users can see all binary versions with their dates in a folder, and they are used to that, so they'll probably ask for it if this gets removed without replacement.

Regarding Downloader (update_all doesn't download anything directly, just calls downloader), there is no need to change anything. And the related "con" you mentioned is not a concern since that tool was designed to remove previously installed files since the beginning. What would have to be changed is the JTCORES database scripts here: https://github.com/jotego/jtcores_mister/blob/main/.github/update_jtcores.sh and here: https://github.com/jotego/jtpremium/blob/main/.github/update_jtcores.sh so that they grab the RBF files without dates instead.

[jotego]

-[X] Merged PRs from @theypsilon in jtpremium and jtcores_mister repos
-[X] Updated the compilation workflow so files are not timestamped
-[X] Removed all dated RBF files from JTBIN in 9775f01