stm32cubeide{,_1_19_0}: init at 2.1.1/1.19.0

[sempiternal-aurora]

Package stm32cubeide for use in nixpkgs. Goes along with stm32cubemx, which we already have here. Source for the project requires agreeing to a EULA, and providing an name/email to st, so I have built it to use pkgs.requireFile like mathematica does. A few things I'm unsure about, which is why I'm leaving this as a draft for now:

• I'm not sure how functional the actual IDE is. Going to be using it for the next few weeks, so I'll bug test it and see how it goes. Don't think it'll be ready in time for feature freeze sadly.
• Not sure what the maintenance burden will be in keeping all these versions of the IDE will be.
  • Right now, the st-link server version is the same as the latest stm32cubeide version, but for all of the stm32cubeide versions I've packaged here.
  • I think this is just a coincidence, as the current st-link server version seems to have been around since 2024 at the very least, but I'm not 100% confident.
  • Basically, I'm worried they'll rebuild all recent versions of the software when a new stm32cubeide release comes out, and I don't want to re-download 8 1GB files every time a new version comes out.
• Further, with the versions, do we need more than latest 2.x and 1.x versions?
  • I originally got them all based on what mathematica does, but they have more reason to do it there, as software version is tied directly to licences
  • It doesn't really seem like we'd need more than stm32cubeide, and stm32cubeide1?
    • Not quite sure on the name for the second one there.
• Also worth considering, do we want to create a separate derivation for stlink-server?
  • It seems like it can be used without stm32cubeide, and does have a separate upstream download link.
  • I don't think it's really necessary right now, and will cause users of stm32cubeide to have to provide 2 different files to the nix-store, one of which is redundant.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.