[RFC] Remove all dependencies on external binaries

The native resolvers are used for the Kernel Symbol resolution in the
`BPF` class, and for the ProcessSymbols class. A lot of redundant code
has been removed.

The `sym` module no longer needs to be exported. The `LD` module is no
longer used anywhere.

The static `BPF.SymbolCache` now uses a native symbol resolver instead
of the Lua/binutils implementation. Likewise for the kernel symbol
resolver, and the `check_path_symbol` API to find a probe's hook
address.

This new set of C/C++ APIs is capable of performing symbol resolution
for any given running process, using the native `libelf` APIs instead of
shelling out to binutils tools.

This is a reimplementation of the original ProcSyms Python/Lua code.

These APIs mimic behavior that was being performed using native tools.

- bcc_procutils_which_so: resolves a short library name into a full path
  so a shared object. Equivalent to `ldconfig -p`
- bcc_procutils_which: resolves a short name into a full path to a
  binary. Equivalent to a shell's builtin `which`
- bcc_procutils_each_module: lists all the modules loaded in a process'
  memory space. Uses the kernel's `/proc/$pid/maps`
- bcc_procutils_each_ksym: lists all symbols and addresses for the
  kernel. Uses the kernel's `/proc/kallsyms`

The following APIs have been implemented inside `libbcc`, which
programatically replicate the previous usage of `binutils` tools like
`objdump` and `elfdump`.

- bcc_elf_foreach_usdt: finds all USDT probes inside a given binary
- bcc_elf_loadadddr: find the load address for a shared object
- bcc_elf_foreach_sym: lists all symbols in an ELF binary or SO
- bcc_elf_shared_obj: returns whether a given path is an ELF shared
  object, a binary, or neither

Add a new a `FindLibElf.cmake` package, and use it to link the main
`libbcc` library against the system's LibELF. This library will be used
to re-implement functionality that was previously dependent on
`binutils`.

Instead of importing the `Find*.cmake` modules directly, place them in
the root `cmake/` folder and define it as a CMake Module path. This lets
us use the `find_package` builtin to require any given packages.

Add infra and ctest for code style formatting

Add an initial .clang-format file, based on LLVM's style base. Inform
the style-check wrapper to only consider h, c, and cc files when it
runs, and print out the --verbose output upon failure.

When user touches a file, that file will be fed to `git clang-format`,
and if the tool reports a new diff it will consider the test failed. The
files to check will be anything in the current workspace compared to
origin/master.

Update INSTALL.md with Xenial instructions

The buildbot is now building nightly ubuntu 16.04 packages. Include the steps to install.

Let bcc debian build depend on 3.7|3.8

In Xenial, llvm 3.8 will be available upstream without manual apt steps.
Add those packages as a possible dependency in our build.

Don't require "OS ABI" specification in libraries

lua: Properly support high-range 64 addresses

Install all required packages on ubuntu

The most important system libraries are listed like this by ldconfig:

	libc.so.6 (libc6,x86-64, OS ABI: Linux 3.0.0) => /lib64/libc.so.6

But most user-level libraries don't have the "OS ABI" and will not be
found by the regular expression.

	libz.so (libc6,x86-64) => /usr/lib64/libz.so

This makes the regular expression more permissive, so that it finds
those libraries as well.

Lua's native Number type is a 64-bit double with 52-bit precision, which
was causing rounding errors when storing and working with high-range
memory addresses (namely, addresses from the kernel, which are all in
the `0xffffffff........` range).

To work around this, we've made sure to never call `tonumber` on any
variables that represent memory addresses, and instead continue
operating on them with their native types: LuaJIT can work with the
underlying `uint64_t` type for these values and transparently perform
all kinds of numeric operations.

The only limitation of working with native 64-bit types in LuaJIT is
that they cannot be printed with the language's default `string.format`
API. To give better UX to probe writers, these APIs have been
monkeypatched so the `%p` format specifier will now properly handle
64-bit addresses and print them in an appropriate format.

bcc-lua: build bcc.lua and bcc.o in the build tree

miscellaneous cleanups to C++ and tools/trace

I didn't actually track this one down, but was getting some errors
coming out of kernel header files when perf_events.h was included first.
Move it after some std headers that mask the issue.

BPF programs aren't allowed to attach to these functions since deadlocks
may occur, thus the test would fail since no stack is collected. Use
update_elem to test instead.