This patch adds a command running option to bpftrace. The user can now
run something like:

    ./bpftrace -e '...' -c 'sleep 5'

which is a convenience wrapper around something like:

    sleep 5 & ./bpfrace -e '...' -p `pidof sleep`

`-c` is better because it:
* ensures a tighter tracing range around CMD (ie we trace less of the
system while it is not running CMD)
* makes bpftrace exit (which is convenient) when CMD terminates
    * previously, it was not possible to get a full trace of CMDs
    execution and have bpftrace exit upon CMD termination

Test Plan:
Trivial successful example:
```
$ sudo ./build/src/bpftrace -e 'tracepoint:syscalls:sys_enter_nanosleep
{ printf("%s nanoslept\n", comm); }' -c '/bin/sleep 1'
[sudo] password for dlxu:
chdir(/lib/modules/4.19.8-200.fc28.x86_64/build): No such file or
directory
Attaching 1 probe...
sleep nanoslept
splunkd nanoslept
webrtc_audio_mo nanoslept
gnome-terminal- nanoslept
webrtc_audio_mo nanoslept
gnome-terminal- nanoslept
gnome-terminal- nanoslept
gnome-terminal- nanoslept
gnome-terminal- nanoslept
gnome-terminal- nanoslept
gnome-terminal- nanoslept
gnome-terminal- nanoslept
gnome-terminal- nanoslept
gnome-terminal- nanoslept
gnome-terminal- nanoslept

$
```

Ambigous executable:
```
$ sudo ./build/src/bpftrace -e 'tracepoint:syscalls:sys_enter_nanosleep
{ printf("%s nanoslept\n", comm); }' -c 'sleep 1'
chdir(/lib/modules/4.19.8-200.fc28.x86_64/build): No such file or
directory
Attaching 1 probe...
execve: No such file or directory
Failed to spawn child=sleep 1
splunkd nanoslept

$
```

This closes #253

Normalize bpftrace(8) man page

This patch normalizes parts of the man page to be in line with the rest.

If the user provides a specific PID to trace, it doesn't really make
sense to keep running if the tracee terminates. This patch makes
bpftrace exit cleanly if the tracee terminates.

I spent quite a bit of time thinking about the generic problem of
figuring out when an arbitrary pid terminates. After some experiments,
here is what I've learned:
* wait(2) and waitpid(2) can only wait on child processes (duh)
* epoll(2) does not support procfs (or other pseudo filesystems)
* inotify does not support procfs either b/c procfs changes are not made
through the filesystem (by another userspace entity)
* ptrace with PTRACE_SEIZE might work but might have extra overhead on
the tracee
* the netlink interface for process state changes seems a bit overkill
* the only sane solution (AFAICT) is to poll /proc/PID/ for changes

Thus, I've made some minor changes to the main event loop to support
polling procfs.

Test Plan:
Make sure non-pid-specific tracing still works:
```
$ sudo ./build/src/bpftrace -e 'uretprobe:/bin/bash:readline { printf("read a line\n"); }'
[sudo] password for dlxu:
Attaching 1 probe...
read a line
read a line
read a line
read a line
read a line
read a line
read a line
read a line
^C

```

Verify pid-specific tracing (ie usdt) exits on tracee termination:
```
// in window 1
$ ./python -q

// in window 2
$ sudo ~/dev/bpftrace/build/src/bpftrace -p $(pidof python) -e 'usdt:/home/dlxu/dev/cpython/python:function__entry { printf("%s %s\n", str(arg0), str(arg1)) }'
[sudo] password for dlxu:
Attaching 1 probe...
<stdin> <module>

// in window 1
>>> print('wow')
wow
>>>

// verify bpftrace has exited in window 2

```

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