Implement a rudimentary core/dll download form

[Morilli]

• (resolves) Offer MAME core as a download, like FFmpeg #3505

This implements a very simple download form that can be used to download additional files into the dll directory, mainly intended to be used for large core downloads, such as the mame or encore cores. This, in addition to excluding those files from the release zips can help bring the initial download size of bizhawk down.

How it currently looks like (accessable from Tools->Download cores):

PRing for visibility and feedback. I think this could work as is, but probably needs additional support from the excluded cores to not feel bad when a user tries to load a ROM for a core that isn't downloaded and is then presented with an undecipherable error message.

Disclaimer: I do not take responsibility for the diff in Mainform.Designer.cs.

Check if completed:

• I have run any relevant test suites
• I, the committer, have read the licensing terms for contributors (last updated 2024-03-20) and am compliant

[YoshiRulz]

Having FFmpeg in https://github.com/TASEmulators/ffmpeg-binaries makes sense because it doesn't change. Before hosting any core binaries in a GitHub repo like that, we need to plan ahead and decide on a versioning scheme, a way to check compatibility (in case it's downloaded manually), and an expiration date for URIs (#2235). We also need to decide how dev builds should behave.

[Morilli]

Right, this is one of the things that need to be decided before this can work. In this implementation I was thinking of having a separate repository (just like ffmpeg-binaries) that hosts downloadable dlls for each released bizhawk version in a separate branch, so for release 2.9.2 you would have a 2.9.2 branch with the binaries from that release. Those would of course stay static after the release.

It would probably also be possible to fetch the binaries from the BizHawk repo itself using the release tag, but that feels a little more volatile in regards to future-proofness.
I see your point in that potentially breaking this download in the future because we don't control the url anymore would be bad, but I don't see how this case here differs from the ffmpeg download case.
Compatibility checking could be implemented but I personally wouldn't bother, because as long as we serve proper downloads compatibility should be guaranteed, and if people download stuff on their own, well, that's their own problem (you can already replace any non-bizhawk dlls and cores with different versions).

We also need to decide how dev builds should behave.

I say ignore that case completely, dev builds can stay being full-size downloads and one dev 2.9.2 has little meaning when it could span an entire year of changes, so those downloads don't need to work (or be valid working files) for dev builds.