Optionally create full debuginfo for llvm-related executables

Commit de6feefdb7cfd limited the amount of debuginfo generated for clang
and other llvm-related executables. This was done to save disk space and
memory during building, but it makes debugging any of these executables
much harder.

Add a new src.conf(5) setting, WITH_LLVM_FULL_DEBUGINFO, to generate
full debuginfo instead. This is off by default, but could for example be
enabled for release builds or snapshots, so llvm executables are easier
to debug.

Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43839

Revert "Build clang and other llvm executables as PIE"

This reverts commit 470f9f13de10e47e6d45721c15af6b4abe7aad55.

I need more time to figure out how to make this work correctly with
incremental builds, which it currently miserably fails on.

Build clang and other llvm executables as PIE

There is no reason anymore to not build these as PIE. Unfortunately
bsd.lib.mk does not allow for building _only_ PIE static libraries, so
lib/clang/Makefile.inc needs a kludge to work around that issue.

MFC after: 1 week

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Remove LLVM build glue for MIPS as a native architecture.

This does not remove LLVM_TARGET_MIPS. Note that the only
MACHINE_ARCH values ending in 'hf' were all MIPS architectures, hence
removing the pattern matches for 'hf'.

Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D39331

clang: use -mxgot for 32-bit mips

Various bits in usr.bin/clang/* will fail to compile without -mxgot due to
truncated relocations. -mxgot entails a speed penalty, but I suspect we
don't care as much about compiler performance in 32-bit mips land.

Reviewed by: arichardson
Differential Revision: https://reviews.freebsd.org/D21698

Add WITH_PIE knob to build Position Independent Executables

Building binaries as PIE allows the executable itself to be loaded at a
random address when ASLR is enabled (not just its shared libraries).

With this change PIE objects have a .pieo extension and INTERNALLIB
libraries libXXX_pie.a.

MK_PIE is disabled for some kerberos5 tools, Clang, and Subversion, as
they explicitly reference .a libraries in their Makefiles. These can
be addressed on an individual basis later. MK_PIE is also disabled for
rtld-elf because it is already position-independent using bespoke
Makefile rules.

Currently only dynamically linked binaries will be built as PIE.

Discussed with: dim
Reviewed by: kib
MFC after: 1 month
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18423

Improve the coverage of debug symbols for MK_DEBUG_FILES.

- Include debug symbols in static libraries. This permits binaries
to include debug symbols for functions obtained from static libraries.
- Permit the C/C++ compiler flags added for MK_DEBUG_FILES to be
overridden by setting DEBUG_FILES_CFLAGS. Use this to limit the debug
information for llvm libraries and binaries.

Reviewed by: emaste
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D12025

Undo r305299, since it also sets up BINDIR, via usr.bin/Makefile.inc.
Just set WARNS to zero instead.

For now, undo the WARNS=3 setting for the clang and llvm tools. More
work needs to be done first to get everything compiling without warnings.

Compile clang, lldb and related tools with WARNS=3 by default.

Completely revamp the way llvm, clang and lldb are built.

* Bootstrap llvm-tblgen and clang-tblgen with a minimal llvm static
library, that has no other dependencies.
* Roll up all separate llvm libraries into one big static libllvm.
* Similar for all separate clang and lldb static libraries.
* For all these libraries, generate their .inc files only once.
* Link all llvm tools (including extra) against the big libllvm.
* Link clang and clang-format against the big libllvm and libclang.
* Link lldb against the big libllvm, libclang and liblldb.

N.B.: This is work in progress, some details may still be missing.

It also heavily depends on bsd.*.mk's support for SRCS and DPSRCS with
relative pathnames, which apparently does not always work as expected.
For building llvm, clang and lldb though, it seems to work just fine.

The main idea behind this restructuring is maintainability and build
peformance. The previous large number of very small libraries, each
with their own generated files and dependencies was slow to traverse
and hard to understand.

Possible future improvements:
* Only build certain targets, e.g. for most regular users having just
one target will be fine. This will shave off some build time.
* Building the big llvm, clang and lldb libraries as shared (private)
libraries.
* Adding other components from the LLVM project, such as lld.