dmenu, slstatus, st, dwm, slock: add updateScript

[Qusic]

Description of changes

• Add updateScript for a few suckless packages
• Add myself to and remove inactive @andsild from st package maintainers, as pointed out by @AndersonTorres

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[AndersonTorres]

Split the packages into dedicated commits.

Indeed I would suggest one for each PR.

[AndersonTorres]

A suggestion of workflow:

1. In your local copy, synchronize master
2. Create and checkout a branch called (say) maintainers-add-qusic
3. In add-qusic-to-maintainers create a commit adding qusic to maintainers
4. For each package P you want to adopt
   1. Create a new branch from maintainers-add-qusic called P-adopt
   2. Create a commit doing your changes

Then, create PRs for each of those commits.
However, you will mark all as draft except the maintainers-add-qusic, and you will explain that your intention is to became the new maintainer of the P-adopt packages.

What do you think?

The idea is that you can rebase them later more easily without the need for waiting for you being added to maintainers first.

[Qusic]

@AndersonTorres Thanks for the tip! I am out this weekend without my PC and will create separate PRs next week. I close this for now so CI validations can stop and free up some resources.