qemu: Restore missing libutil dependency for OS X < 10.5.

[akemin-dayo]

This allows QEMU to successfully build again on OS X 10.4.

This dependency was previously added in commit cca45a2, but was inadvertently erroneously removed when the QEMU version was reverted to 2.2.1 in commit b5c0b67.

---

Without this dependency installed, QEMU fails to build because ld fails to link against libutil (which seemingly does not exist on 10.4.x, but does in 10.5.x).

/usr/local/bin/g++-4.2 -I/usr/local/Cellar/pixman/0.32.6/include/pixman-1 -I/private/tmp/qemu20211013-28372-1w1cg35/qemu-2.2.1/dtc/libfdt -DHAS_LIBSSH2_SFTP_FSYNC -m32 -DOS_OBJECT_USE_OBJC=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common  -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/Cellar/gnutls/3.3.18/include -I/usr/local/Cellar/nettle/2.7.1/include -I/usr/local/Cellar/libtasn1/4.7/include -I/usr/local/Cellar/gnutls/3.3.18/include -I/usr/local/Cellar/nettle/2.7.1/include -I/usr/local/Cellar/libtasn1/4.7/include  -I/private/tmp/qemu20211013-28372-1w1cg35/qemu-2.2.1/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_REENTRANT -I/usr/local/Cellar/glib/2.50.1/include/glib-2.0 -I/usr/local/Cellar/glib/2.50.1/lib/glib-2.0/include -I/usr/local/opt/gettext/include -I/usr/local/Cellar/pcre/8.39/include -g -Os -w -pipe -mcpu=7400 -faltivec -mmacosx-version-min=10.4 -D__STDC_CONSTANT_MACROS -m32 -framework CoreFoundation -framework IOKit -g -L/usr/local/opt/pixman/lib -L/usr/local/opt/zlib/lib -L/usr/local/opt/gettext/lib -L/usr/local/opt/libtool/lib -L/usr/local/lib -F/usr/local/Frameworks -Wl,-headerpad_max_install_names -o qemu-nbd qemu-nbd.o async.o thread-pool.o nbd.o block.o blockjob.o main-loop.o iohandler.o qemu-timer.o aio-posix.o qemu-io-cmds.o qemu-coroutine.o qemu-coroutine-lock.o qemu-coroutine-io.o qemu-coroutine-sleep.o coroutine-sigaltstack.o block/raw_bsd.o block/qcow.o block/vdi.o block/vmdk.o block/cloop.o block/dmg.o block/bochs.o block/vpc.o block/vvfat.o block/qcow2.o block/qcow2-refcount.o block/qcow2-cluster.o block/qcow2-snapshot.o block/qcow2-cache.o block/qed.o block/qed-gencb.o block/qed-l2-cache.o block/qed-table.o block/qed-cluster.o block/qed-check.o block/vhdx.o block/vhdx-endian.o block/vhdx-log.o block/quorum.o block/parallels.o block/blkdebug.o block/blkverify.o block/block-backend.o block/snapshot.o block/qapi.o block/raw-posix.o block/null.o block/mirror.o block/nbd.o block/nbd-client.o block/sheepdog.o block/accounting.o block/ssh.o  libqemuutil.a libqemustub.a   -lz -L/usr/local/Cellar/libssh2/1.8.0/lib -lssh2 -L/usr/local/Cellar/glib/2.50.1/lib -L/usr/local/opt/gettext/lib -lgthread-2.0 -lglib-2.0 -lintl  -lz -lz -L/usr/local/Cellar/gnutls/3.3.18/lib -lgnutls -L/usr/local/Cellar/gnutls/3.3.18/lib -lgnutls -L/usr/local/Cellar/gnutls/3.3.18/lib -lgnutls -F/System/Library/Frameworks -framework Cocoa -framework IOKit  -lutil
/usr/bin/ld: can't locate file for: -lutil
collect2: ld returned 1 exit status
gmake: *** [/private/tmp/qemu20211013-28372-1w1cg35/qemu-2.2.1/rules.mak:122: qemu-nbd] Error 1

---

brew install qemu → PASS (OS X 10.5.8 [--cc=gcc-7 is required, a future PR will address this] and OS X 10.4.11, both PowerPC)
brew audit qemu → PASS
brew test qemu → PASS (PR #769 required)

[akemin-dayo]

Also, I do have a question for the Tigerbrew maintainers (… if there are any who aren't Misty…?): As you can see here, I split my QEMU-related changes into not just two commits, but also two PRs (the other being #766).

Is this preferable? Or would you rather have just one PR and/or one commit making larger changes?

The logic behind why I split my changes into two commits/PRs is mostly because this would allow Tigerbrew maintainers to partially merge just one set of changes. The libutil missing dependency fix (here) is to me, a critical fix, as QEMU completely fails to build on OS X 10.4 without it being present, while the other change in #766 is pretty much just an enhancement/improvement to the default build settings.

The main reason why I'm asking is because I'm planning to (already did: PR #768) submit a new PR for another formula very soon (the changes / fixes are already done, I'm just waiting on a final round of build testing to make sure everything still works before submission) and I'd like to know what preferences, if any that you have on splitting out changes into commits (which I couldn't really find anything about in CONTRIBUTING.md).

---

And for a much less relevant question to this PR, what's the stance on the contributing of binary bottles?

I've just been assuming that user-contributed bottles are completely unacceptable due to security concerns (for instance, if someone with malicious intent includes malware in a bottle).

If this is in fact somehow not the case, then I would be more than happy to contribute some bottles (for leopard_g4 and tiger_g4 only), at least for some formulae that I personally used.