Linux: Don't default to ld.gold linker & fix TLS range with static x86/x64 druntime

[kinke]

I hope the issues with old bfd aren't really a thing anymore.

The main reason is that the user might have set LLD as default /usr/bin/ld symlink, and LDC not using it by default isn't intuitive. And LLD can be significantly faster than gold.

[kinke]

For reference, here are some linking times on Ubuntu 20.04 for a pretty large executable (~1.1 GB with debuginfos, FWIW compiled with DMD) using the distro linkers:

bfd v2.34:
	Elapsed (wall clock) time (h:mm:ss or m:ss): 1:26.59
	Maximum resident set size (kbytes): 16211232

gold v1.16 (from binutils v2.34):
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:18.23
	Maximum resident set size (kbytes): 10524112

lld v10.0.0:
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:05.48
	Maximum resident set size (kbytes): 6338564

[kinke]

Oh, lld is more picky than gold, and rightfully so:

ld: error: duplicate symbol: std::bad_exception::~bad_exception()
>>> defined in /usr/lib/gcc/x86_64-linux-gnu/10/libstdc++.a(eh_exception.o)
>>> defined in /home/vsts/work/1/bootstrap-ldc/lib/libdruntime-ldc-lto.a(exception.bc.o)

ld: error: duplicate symbol: std::bad_cast::~bad_cast()
>>> defined in /home/vsts/work/1/bootstrap-ldc/lib/libdruntime-ldc-lto.a(typeinfo.bc.o)
>>> defined in /usr/lib/gcc/x86_64-linux-gnu/10/libstdc++.a(bad_cast.o)

ld: error: duplicate symbol: std::bad_typeid::~bad_typeid()
>>> defined in /home/vsts/work/1/bootstrap-ldc/lib/libdruntime-ldc-lto.a(typeinfo.bc.o)
>>> defined in /usr/lib/gcc/x86_64-linux-gnu/10/libstdc++.a(bad_typeid.o)

These are auto-generated dtors which don't inherit the @weak UDA of the dtor in the base class...

[kinke]

The frontend workaround is now proposed as dlang/dmd#13167. It's really just a workaround for simple cases like this, and just addressing the IMO oddity that derived C++ classes get a superfluous dtor, even if they don't introduce any new fields requiring destruction or user dtors. The @weak UDA limitation only affecting the user dtor is still in place.

Not using gold has led to #3849. And the LTO lit-tests with lld run into #3786 apparently.