Rework project to allow multiple package sets

[bobvanderlinden]

Currently there are a couple of problems with this project/repository:

• Updates rely on complex mechanism that writes .nix files in various places inside of versions/.
• Applying patches and overrides relies on the directory structure inside of versions/. This isn't flexible enough for some of the patches. For instance, applying overrides ranging over multiple major versions (but only part of the minor version) requires duplication of code and makes it hard to keep overview of these patches.
• It solely supports updating Ruby. Where-as rubygems is also related and needs updating. A more generalized way to update packages would be nice.

This PR introduces the concept of pkgsets. Ruby is one pkgset and rubygems is another. Both can have individual updating mechanisms. In addition, each pkgset has a generic package-fn that produces a derivation. Lastly, they include a list of overrides where (based on a version-condition) will apply specific overrides, like patches or different inputs (openssl -> openssl_1_1).

The updating of Ruby has been overhauled so that it has a simpler structure. The updater now produces a single .json file that includes all version source information (urls and hashes) in addition to aliases of versions (which version is referred to when referring to only a major version?).

Lastly the mkRuby function has been deprecated. It still works, but now packages are exposed like they are for flakes. packages and overlays. These expose package names like ruby-3.0.1, ruby-2.7 and ruby-2. It should be easier to refer to these packages instead of using mkRuby.

[bobvanderlinden]

It's ready. The last build failure was because of specific changes in 3.1.3, for which adding Rubygems 'manually' inside the build caused more harm than good. This version is not in nixpkgs yet, so I didn't have a good example how to fix this properly. I looked at other distros who packaged 3.1.3. Both Guix and ArchLinux didn't use the method of adding Rubygems manually. I thought it might be better to just remove the custom Rubygems for future builds. It's probably a good idea to see which versions of Ruby actually need a custom Rubygems version. And figure out what the purpose was of the custom Rubygems.

Also, the package-fn of Ruby is still lacking some features that are already in nixpkgs. I can look into this at a later time. The cached builds and simplified project structure are atm more important.