CI: monthly build, ability to manually trigger GitHub Actions for specific Ghidra versions

[SmileyAG]

Closes #21

• Replaced compilation for multiple Ghidra versions with the latest version
• In addition to the change above, the ability to specify the version(s) when manually triggering GitHub Actions was added (so that anyone who wants support for their version of Ghidra from the latest master only needs to fork the repository and choose to build the desired version, perhaps this should be noted in README.md, idk)
• Added a monthly build (this is in case the current code became incompatible when building with the latest version of Ghidra or if something in the CI itself broke, like outdated versions of actions)

[antoniovazquezblanco]

A couple of comments:

1. I don't see the need to build monthly, the project should be built when changes are commited. Why do you want to build periodically?
2. Compiling for different Ghidra versions is positive for me. Plugins may not be compatible between versions and this helps tests that and produces releases for all the compatible apis. Why delete that?

Thanks!

[SmileyAG]

I don't see the need to build monthly, the project should be built when changes are commited. Why do you want to build periodically?

It really makes sense to do a monthly build to check that the current code still builds successfully with the latest version of Ghidra, secondly, to check if some of the other actions are outdated and maybe they should be upgraded or their parameters changed (at a minimum, this can only cause warnings, at most, CI will start giving an error during the build), thirdly, if a lot of changes were made, and there was no official release, then this will allow you to still get the current unreleased version, in addition, in GitHub Actions, artifacts can be stored for up to 3 months from the moment of their build, after which they become unavailable. So in a monthly build there are only advantages from this, I was convinced of this when working with CI in other projects. Just think of it as a kind of preventative measure.

Compiling for different Ghidra versions is positive for me. Plugins may not be compatible between versions and this helps tests that and produces releases for all the compatible apis. Why delete that?

I can return the rest of the versions, but it seems to me that it is not very good to make 8+ or so builds per each trigger (push, pull_request, workflow_dispatch), when we can only build for the latest version and maybe a few more that are important to us, and those who need to build for their version can simply fork the repository, go to Actions, enter the desired version in the field and start the process - it's literally a couple of clicks and you don't need to change anything in the CI code, literally anyone can figure it out (we can leave a note about this in README.md if needed):

[ubfx]

I also think the automatic build for a set of (reasonably) recent ghidra versions makes sense. Since github hosts the runner and artifacts, I see no issue with having a bunch of runs triggered each time. If this saves a user some time and hassle, that's a worthwile investment. But having an additional periodical build against "latest" ghidra version can't hurt either.

[SmileyAG]

Yeah, it all makes sense now. In general, the model to compile the latest build version, a couple of stable build versions up to a specific version and also to have the optional ability to try manually build for the specified versions in a few clicks - sounds so perfect. This should clearly be enough.