wayland: build libraries on darwin

[wegank]

Description of changes

This PR includes a minimal patch that allows building Wayland libraries on Darwin. The patch is rather trivial, and should be extensible to support more exotic platforms. The patch is also compatible with version 1.21.92.

The reason for doing it downstream is that upstream seems to be less active in supporting more exotic platforms. The PR for the OpenBSD port has been stalled for 7 months, for example.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 23.05 Release Notes (or backporting 22.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.

[lovesegfault]

I favor this, but IMO we should:

1. Open an upstream PR anyway
2. Use the patch generated from the upstream commit, so that in the future rebasing the patch is easy (git am to release tag, rebase, git format-patch)

[wegank]

1. Open an upstream PR anyway

There are currently four upstream MRs for the macOS port. While !290 and !254 are (much heavier) supersets of the patch in this PR, !303 clearly forms a subset, so I'd rather wait for it to be merged first. Also, since all of them are stalled, I don't think there's a need for opening a fifth MR.

2. Use the patch generated from the upstream commit, so that in the future rebasing the patch is easy (git am to release tag, rebase, git format-patch)

This could be troublesome if we consider BSDs in the future, as patches from different MRs might overlap or not be compatible.