[tests] Fix codegen tests for LLVM 5, 6 and 7

bpftrace adaptations of several iovisor/bcc tcp*.py tools

Extract LINUX_VERSION_CODE from running kernel via vDSO.

Fedora 27 and LLVM 5 are EOL, which means they won't receive new
updates (not even security patches). As such, there's no reason to keep
testing those platforms/dependencies in our CI, and removing them will
reduce our CI complexity as well as unbreak our CI.

Also, static builds are broken for some time
(https://github.com/iovisor/bpftrace/issues/266), and keeping them in
our CI will only prevent collaborators from keeping the CI healthy. We
should push for Ubuntu/Debian/Fedora static builds instead of relying on
alpine for it. For now, mark alpine static build as "allow to fail" on
Travis.

This method reuses a stable interface provided for glibc, avoids runtime
header file parsing or regexes, and the vDSO structure should remain
stable over time. Fall back to the compile time constant if search
fails.

Initial inet_ntop implementation

Use LLVM_VERSION_MAJOR checks to make codegen tests work on LLVM 5, 6 and 7.

The 'bpftrace -l' command (without any search expression) should also
list the tracepoints, in the same way of 'bpftrace -l '*''.

Fix random small typos and mistakes in man pages

Fix possible crash on exit due to wrong vector size (#201)

Document unroll

Add fedora package install instructions to INSTALL.md

On method BPFtrace::find_empty_key() size of 'value' vector (value_size)
must be multiplied by ncpus_ when map.type_.type == Type::lhist
otherwise bpf syscall (BPF_MAP_LOOKUP_ELEM) will write out of bounds
thus corrupting the heap.

Fixes: https://github.com/iovisor/bpftrace/issues/251

Support for split LLVM libs

Support for split LLVM libs is added since Gentoo does not distribute a
combined LLVM library.

fix map keying with 1 or 2 byte integers (#232)

User-space stacks are quite special in regards to aggregation (and
comparison) between processes. To a first approximation, each pid has a
different memory mapping and thus pointers should not be compared or
aggregated between pids[*]. With ASLR this becomes even more fun, and
thus it is necessary to do usym()-style packing of the stackid for
ustack (since bpf_get_stackid will give you a hash of the pointers --
even in the ustack case).

However, the kernel address space is the same regardless of current->pid
-- and in many cases you want to aggregate between different processes
(and if not, you can always do the packing yourself with @[tid,stack]).

So, we only apply the packing when dealing with ustack. sym() already
does the right thing.

[*] This is more than slightly untrue -- really this depends on
    current->mm and ideally we would aggregate ustack on current->mm.
    Unfortunately this is not a luxury we have at the moment.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Fix USAGE message (issue 191)

- Stop warning about '-h'
- Sort options alphabetically
- Cosmetic changes

Fix 'lhist() 0 entry has 0M' (issue 63)