macho: check for control flow instrumentation #21889

Addresses the macOS portion of #21888.

Build Boost with -fcf-protection when targeting Darwin. This should be ok, because our cross-compiler (Clang 10) supports the option, and I'd expect all versions of Apple Clang being used to compile Core would also support it. Building Boost with this option is required so that the main provided to test_bitcoin has instrumentation.

Note that the presence of instrumentation does not mean it will be used, as that is determined at runtime by the CPU. From the Intel control flow enforcement documentation:

The ENDBR32 and ENDBR64 instructions will have the same effect as the NOP instruction on Intel 64 processors that do not support CET. On processors supporting CET, these instructions do not change register or flag state. This allows CET instrumented programs to execute on processors that do not support CET. Even when CET is supported and enabled, these NOP–like instructions do not affect the execution state of the program, do not cause any additional register pressure, and are minimally intrusive from power and performance perspectives.

Follow up from #21135.

Guix builds:

663df8471400f06d4da739e39a886aa17f56a36d66e0ff7cc290686294ef39c9  guix-build-42b589d18fed/output/dist-archive/bitcoin-42b589d18fed.tar.gz
45e841661e1659a634468b6f8c9fb0a7956c31ba296f1fd0c02cd880736d6127  guix-build-42b589d18fed/output/x86_64-apple-darwin18/bitcoin-42b589d18fed-osx-unsigned.dmg
0ea85c99fef35429a5048fa14850bce6b900eaa887aeea419b019852f8d2be78  guix-build-42b589d18fed/output/x86_64-apple-darwin18/bitcoin-42b589d18fed-osx-unsigned.tar.gz
85857a5a4a5d4d3a172d6c361c12c4a94f6505fc12b527ea63b75bfe54ee1001  guix-build-42b589d18fed/output/x86_64-apple-darwin18/bitcoin-42b589d18fed-osx64.tar.gz

Gitian builds:

# macOS:
bdfd677a6b88273a741b433e1e7f554af50cc76b3342d44ab0c441e2b40efc96  bitcoin-42b589d18fed-osx-unsigned.dmg
f3b2d09f3bea7a5cc489b02e8e53dd76a9922338500fae79cad0506655af56f9  bitcoin-42b589d18fed-osx-unsigned.tar.gz
29d5ad5e46bc9fb0056922a8b47c026e5e9f71e6cf447203b74644587d6fb6f7  bitcoin-42b589d18fed-osx64.tar.gz
663df8471400f06d4da739e39a886aa17f56a36d66e0ff7cc290686294ef39c9  src/bitcoin-42b589d18fed.tar.gz
366f8d7a2fc1f3e22cb1018043099126a71ce65380cc27b1c3280cce42d06c98  bitcoin-core-osx-22-res.yml

Code review ACK 42b589d18fed5e2b3cb6ac9937e3333619967a6c Haven't tested on the target platform.

<!--9cd9c72976c961c55c7acef8f6ba82cd-->

Guix builds

<!--a722867cd34abeea1fadc8d60700f111-->

Gitian builds

As a future direction I'm wondering if FCF checking should check every function in the program, not just the outer function. This would make sure that all code was built with it enabled not just a single object.

E.g. the only reason we discovered the lack of it in boost is because the test uses it for main.

That said, checking one is enough to know if the gcc flag was enabled, and we do the same kind of spot check for the other checks (like stack protection), so this is good to get started.