treewide: change the occurrences of "name" to "pname-version"

[AndersonTorres]

Motivation for this change

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[RaghavSood]

For some requests, I had to leave comments instead of suggestions as GitHub seems to limit how many lines around a change you can make a suggestion on

[AndersonTorres]

@RaghavSood many thanks! For now I am just changing the most obvious things.
But I will fix this too.

[RaghavSood]

Certainly - most of my suggestions are simply to fix up stuff missed in the initial commit - the only one that is an actual issue is pkgs/applications/audio/nootka/default.nix -> Looks like one reference to ${name} wasn't changed to ${pname}, so that would break the build

The rest are just adding on to the legwork you already did in updating most scenarios :)

[AndersonTorres]

For now just point the lines.
There is no serious need of using the "suggesting changes" feature of github.

[xaverdh]

While there is certainly consensus to use pname and version instead of name, I am not so sure about changing the repo part in fetchFromGitLab / fetchFromGitHub expressions to use pname.
I am not sure if that's the correct semantics.. the project name might change while still having the source in the same git repository and vice versa. To my mind, these are actually separate pieces of information, that often just happen to agree.

Either way thanks for working on this!

[RaghavSood]

Conversely, if the project has changed their repo name, there's usually a good chance that they are changing the project name, in which case pname should also be updated, and perhaps an alias added for the old one. They would generally continue to agree in that case

I'm not really sure on how often a project + repo renames vs. just renaming the repo, I can't imagine it being terribly common in either scenario - we might see one or two a month across the entire tree

[AndersonTorres]

There are some rare but noteworthy exceptions.
Lomiri still uses the old unity8 name in their repos: https://github.com/ubports/unity8

For now my concerns are

• changing name to pname-version;
• parameterize references to name and version (example: url = http://example.org/beautiful-software-1.5.gz; should be url=http://example.org/${pname}-${version}.gz)

[AndersonTorres]

Why does it rebuild the world?

[AndersonTorres]

/rebase-staging

[github-actions]

Failed to rebase on staging