The symbol alias macros now support macOS, so the patch can be dropped.

The current Git revision has had a lot of work done to it to
better support macOS and lets us drop the huge patch we were using
before. More macOS fixes are apparently on the way, so hopefully the
two that are still required can be dropped on the next release.

native build produces binaries with `#!${bash}/bin/sh` as shebang.
seems to be a consequence of nixpkgs using bash in the builder, and
`patchShebangs` sees that. OTOH cross builds would get `#!/bin/sh` because
the builder's bash isn't eligible as a runtime shebang. i can't say
which is most "correct" in the context of this tool, but shipping bash
in `buildInputs` where `patchShebangs` can see it at least gets us *consistency*.

without this applications won't locate gtk3's schemas even if they're on
XDG_DATA_DIRS. this patch solves runtime errors of the form:
```
Settings schema 'org.gtk.Settings.FileChooser' is not installed
```

protobuf>3.20 allows to use the system GTest. Therefore, we can safely
remove the logic to use third_party/gmock from `generic-v3-cmake.nix`
because it's used only for protobuf>=3.21.

TIme to time I bump into pathological behaviour of `bash` memory
allocator. Today's example:

    $ time { ls /nix/store/ > /dev/null; }
    real    0m0,965s user    0m0,876s sys     0m0,087s
    $ time { echo /nix/store/* > /dev/null; }
    real    2m18,287s user    2m17,946s sys     0m0,125s
    $ time { echo /nix/store/* > /dev/null; }
    real    0m1,764s user    0m1,712s sys     0m0,048s

Note how initial `echo` takes alsmot 2 minutes to finish.

Let's rely  on system's allocator instead.

After the change initial run is fast again:

    $ time { echo /nix/store/* > /dev/null; }
    real    0m1,328s user    0m1,264s sys     0m0,063s

Build needs to run wayland-scanner, so needs a native wayland.

* Apply the patch used for gperf 3.1 in 58f559c; and
* Include `string.h` unconditionally in `lib/getopt.c`.

Without the change `which` fails to find programs on filesystems with
64-bit inodes when `which` itself is 32-bit.

In my case it is `btrfs` and `i686-linux`.

`bison` is in the PATH:

    $ dev>bison
    bison: missing operand
    Try 'bison --help' for more information.

But `which` fails to find it:

    $ which bison
    which: no bison in ...

`bison` is a file with an inode number that overflows 2^31 limit:

    $ stat ~/bin/bison
      File: ~/bin/bison
      Size: 674260          Blocks: 1320       IO Block: 4096   regular file
    Device: 0,29    Inode: 4384368825  Links: 2
    Access: (0555/-r-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2023-09-05 04:48:43.000000000 +0100
    Modify: 1970-01-01 01:00:01.000000000 +0100
    Change: 2023-09-05 04:48:43.821566578 +0100
     Birth: 2023-09-05 04:48:43.772565733 +0100

The change fixes `which` run.

ffmpeg_4 crashes in `ff_seek_frame_binary` due to UB and optimizations
clang 16 performs. This is fixed upstream in ffmpeg_5, but the patch can
be made to apply to ffmpeg_4.

Remove usage of the register storage class, which is not allowed in
C++17 (the default for clang 16).

Feel free to find a better solution.  This is just a simple
mass-regression stop-gap, as noone seems to care about the failure.

#252097 (comment)

abseil-cpp version hell makes it hard to switch versions (as I feared)
https://hydra.nixos.org/build/236112673/nixlog/1/tail
So let's avoid tests instead, until someone really investigates this.

Really, I was careless.  But at least the default version had it right.

https://hydra.nixos.org/build/235683565/nixlog/3/tail
Blacksmoke16/oq#119