This also removes some now-unnecessary cctools hacks.

Co-Authored-By: Cory Fields <[email protected]>

This also removes the obsolete mlinker-version option

Co-Authored-By: Cory Fields <[email protected]>

Co-Authored-By: Carl Dong <[email protected]>

Previously, we did not include the macOS SDK libc++ headers in our SDK
creation process and instead used whichever libc++ headers shipped with
the clang package we downloaded in depends.

This change adds a script (which works on both GNU/Linux and macOS) to
correctly generate the macOS SDK including the libc++ headers. This can
be thought of as a simplified rewrite of tpoechtrager's script:

https://github.com/tpoechtrager/osxcross/blob/d3392f4eae78f3fa3f1fd065fa423f2712825102/tools/gen_sdk_package.sh

The location within the SDK where we place the libc++ headers is chosen
such that clang's search path detection logic for sysroots would pick up
the headers properly.

We also document this change.

Now that we include the macOS SDK libc++ headers in our macOS SDK
tarball, we no longer need this hack to use the libc++ from our pinned
clang.

clang   6.0.1  -> 8.0.0
cctools 921    -> 949.0.1
ld64    409.12 -> 530

This gets us a newer SDK with c++17 support and retains 10.12
back-compat.

Co-authored-by: Carl Dong <[email protected]>

Without this clang fails to add any newly-added linker features.

Removing this in ca5055a was likely a
regression.

See bitcoin#19240 (comment)
for more discussion.

For now they remain the same, but in the next commit, we will assign
them differently according to wether or not we're using system clang.

This should be caught by the differing clang --version outputs, but because we
haven't yet extracted our pinned clang, the system one is actually used for the
version check. That's not a problem because bumping our pinned clang will
cause a rebuild of everything anyway.

For depends builds this was fixed by fbcfcf6, which deleted the conflicting
headers. When we no longer control the clang installation, we need to ensure
that the SDK's libc++ headers are used rather than the ones shipped with clang.
We can do that by turning off the default include path and hard-coding our own.
This hard-coded path is ok because we control (via SDK packaging) where these
headers end-up.

Side-note: Now that this path is hard-coded in depends, we can potentially
package the SDK differently, as the c++ folder can live wherever is most
convenient for us.

Note that this does not _enable_ lto by default in any way, only hooks up the
machinery for -flto to work correctly.

enable-lto-support is explicitly used for pinned-clang because we know it
works. It is neither enabled nor disabled in the external clang case so that
it can be auto-detected.

tpoechtrager/cctools-port#85 was merged upstream, which
fixes lto detection for external clang with some Linux Distro's including
Ubuntu.

native_ds_store now takes advantage of Pythons ability to decode binary
plists (since 3.4), so we can drop its biplist dependency.

The call to biplist.Data() in custom_dsstore doesn't seem to do anything,
and from what I can tell can just be removed.

See https://docs.python.org/3/library/plistlib.html.
The new API was added in 3.4 and old removed in 3.9.

Aplies a patch to Qt that fixes the non-determinism by modifying Qt. The
source of the non-determinism is how LLVM 8 optimizes qt_intersect_spans
when compiling. The particular optimization that seems to be causing the
problems is that a temp variable is being added for spans->y. For some
reason, when it does this, it chooses different instructions to use when
making that variable. We bypass this problem by patching
qt_intersect_spans to always make and use this local variable.