bpf: Wrap `bcc_procutils_which_so` as `BPF.find_library`

This class method was being used outside of the BPF class in the
`tracer` and `usdt` tools.

Explicitly list the libelf runtime dependency

Add libelf-dev to Ubuntu build deps

This was required on a Debian system, but in lieu of instructions for that distribution, and as Debian users will follow Ubuntu, would you consider verifying it on Ubuntu and accepting this PR?

[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.