Merge cloudabi-clang with cloudabi-toolchain and install more useful tools.

Now that the previous changes to the cloudabi-clang package brought in
more LLVM tools, the package actually became a misnomer. Most of the
tools that it installed are not part of Clang, but of LLVM instead. My
plans of extending it to also install wrappers around man(1) and
pkgconf(1) would make the naming even worse.

The only reason that the cloudabi-clang package was created in the first
place, was because we still had some of the core CloudABI libraries part
of FreeBSD Ports. Now that these libraries are part of their own package
collection, it makes more sense to squash this package together with
cloudabi-toolchain.

The nice thing about installing a wrapper around pkgconf(1) named
${gnu_triple}-pkg-config is that Autoconf now automatically picks it up.
Running ./configure --host=${gnu_triple} is enough to make it detect the
cross compiled libraries it depends on.

Reviewed by:	bapt
Differential Revision:	https://reviews.freebsd.org/D5697

Extend the Binutils ports to allow deletion of specific tools.

For CloudABI I slowly want to switch away from certain tools provided by
Binutils. For example, it would be really nice if we could switch from
GNU ld to LLD some time in the future. LLD is not ready yet. Some bug
fixes didn't manage to land into 3.8 and it doesn't support aarch64
properly. There are already some tools that we can use, such as nm,
objdump, size, ar and ranlib.

Introduce a BUREMOVE variable that can be set in Binutils slave ports to
remove specific utilities that are installed by default. There doesn't
seem to be any other elegant way to solve this. Set a bunch of utilities
by default and then extend cloudabi-clang to set up symlinks to the LLVM
versions of the tools.

Reviewed by:	bapt
Differential Revision:	https://reviews.freebsd.org/D5684

Let the CloudABI toolchain use Clang 3.8 instead of 3.7.

As all of the CloudABI tests also pass with Clang 3.8, I think it may be
wise to just go ahead and upgrade.

Introduce Binutils for CloudABI on aarch64.

When I added the first copy of the CloudABI toolchain to the Ports tree,
I assumed that it would be easily possible to have a single Binutils
port that would support all of the architectures of interest. It seems
that this is not really supported, or simply awkward to use.

Let's just rename the cloudabi-binutils port to cloudabi-binutils-x86_64
and add an additional cloudabi-binutils-aarch64.

Reviewed by:	emaste
Approved by:	bapt
Differential Revision:	https://reviews.freebsd.org/D3919

Let cloudabi-clang install a compiler for aarch64.

Now that CloudABI has been ported over to aarch64, let's extend the
FreeBSD ports to install a functioning toolchain for it.

This change extend the llvm37 port to backport a tiny change that is
needed to make Clang support the CloudABI for aarch64 target (r250416).
This change makes Clang use the right ELFOSABI number, but also makes it
set the right #defines (e.g., __CloudABI__).

It also extends the cloudabi-clang port to set up symlinks against Clang
for aarch64.

Submitted by:	ed
Differential Revision:	https://reviews.freebsd.org/D3906

Let lang/cloudabi-clang follow a stable release.

LLVM 3.7 will be the first release to offer CloudABI support out of the
box. Instead of depending on devel/llvm-devel, switch over to using
devel/llvm37.

Fix dependency

Use the right category.

The port is placed in lang/ so use that instead.

Add cloudabi-clang.

This port adds the necessary symbolic links to make Clang work as a
cross compiler for CloudABI. Clang can automatically derive its target
from argv[0]. We don't need to install another copy of Clang. It is
sufficient to invoke it the right way.

CloudABI support is not yet part of a released version of Clang. This is
why we still need to depend on llvm-devel. My intent is to stick to a
fixed compiler version at one point in time.

PR:		200954
Differential Revision:	https://reviews.freebsd.org/D2885
Approved by:	bapt