Ref: iovisor/bcc#778

funccount now bails early with an error if there are no
functions matching the specified pattern (the same applies
to tracepoints and USDT probes). For example:

```
No functions matched by pattern ^sched:sched_fork$
```

Fixes #789.

funccount: Fix on-CPU hang when attaching to SyS_*

Signed-off-by: Marco Leogrande <marcol@plumgrid.com>

To avoid a potential race with the key zeroing modifying
the next hash key retrieved by the loop in `Table.zero()`,
retrieve all the keys in user space first before starting
the zeroing loop. See discussion on #780.

Tested with `funccount 'SyS_*' -i 1` while running a heavy
read/write test application (`dd`) in the background for
several minutes with no visible issues.

Because we know the number of probes in advance before
attaching them, we can simply preinitialize a fixed-size
array instead of using a BPF map. This avoids potential
deadlocks/hangs/race conditions with the Python program
and internally in the kernel. See also #415, #665, #233
for more discussion.

* profile.py to use new perf support

* Minor adjustments to llcstat docs

Add basic support for BPF perf event 

Avoiding the prepopulation of the location cache allows us
to get rid of the `zero()` call at the end of each interval,
which would hang the program at full CPU. Replaced the
prepopulation with a `lookup_or_init` and the `zero()` call
with a call to `clear()`.

`BPF.get_kprobe_functions` does not filter duplicates, and
as a result may return the same function name more than
once if it appears in /sys/kernel/debug/tracing/available_filter_functions
more than once. Change the function's behavior to filter
out duplicates before returning, so we don't end up
attaching the same kprobe more than once.

trace, argdist: STRCMP helper function

Because `funccount` doesn't use the direct regex attach infrastructure
in the BPF module, it needs its own checking for a maximum probe
limit that would make sense. We use 1000 because that's what the
BPF module uses as well. When trying to attach to more than 1000
probes, we bail out early.

funccount: Generalized for uprobes, tracepoints, and USDT

As part of the funccount work, the kprobe quota test doesn't fail
early when adding multiple kprobes at once (with `event_re`), but
rather only when the 1000th probe is being added. Revert to the old
behavior, which fixes the `test_probe_quota` test. Add similar test
for uprobes, `test_uprobe_quota`, which tests the recently-added
uprobe regex support.

This commit updates `funccount` to support attaching to a set of
user functions, kernel tracepoints, or USDT probes using familiar
syntax. Along the way, the implementation has been updated to use
a separate BPF function for each target function, because using
the instruction pointer to determine the function name doesn't
work for anything other than kprobes. Even though the BPF program
can now be potentially larger, testing with 40-50 attach points
shows no significant overhead compared to the previous version.

Examples of what's now possible:

```
funccount t:block:*
funccount u:node:gc*
funccount -r 'c:(read|write)$'
funccount -p 142 u:ruby:object__create
```

Make the `get_user_functions`, `get_kprobe_functions`, and
`get_tracepoints` methods publicly accessible from the BPF class.
These can then be used by tools that need to do their own work
before attaching programs to a set of functions or tracepoints.

* argdist: linter cleanup

* cpudist: linter cleanup

* execsnoop: linter cleanup

* funclatency: linter cleanup

* gethostlatency: linter cleanup

* hardirqs: linter cleanup

* memleak: linter cleanup

* mountsnoop: linter cleanup

* offcputime: linter cleanup

* softirqs: linter cleanup

* solisten: linter cleanup and u+x mode

* stacksnoop: linter cleanup

* tplist: linter cleanup

* trace: linter cleanup

mysqld_slower: Fix breakage after USDT API change

* trace: Additional include files support

Similarly to `argdist`, `trace` now has a `-I` option for adding
include files that can be used in filter and print expressions.
This also required a slight modification to `argdist`'s syntax
for consistency: where previously we would allow `-I header1 header2`,
we now require `-I header1 -I header2` to avoid any mixups with
which argument is a header file and which is a probe for `trace`.

This is very unlikely to break anyone, because I haven't seen the
`-I` option used at all, not to mention extensively with multiple
headers.

Also made sure the man and example pages are up to date.

* argdist: Update -C and -H switches for consistency

This commit updates `argdist`'s `-H` and `-C` switches for consistency
with the `-I` switch and `trace`'s switches. Specifically, each probe
needs an explicit `-C` or `-H` specifier in front of it. This also
allows safe and understandable mixing of histogram and counting probes,
for example:

```
argdist -C 'p:c:write()' -H 'p::vfs__write(int fd, const void *buf, size_t size):size_t:size#write sizes'
```

* trace: Fix stack trace support for tracepoints

Tracepoint probes don't have a `ctx` argument, it's called `args`
instead. The recently-added stack trace support code didn't take
this into account, and consequently didn't work for tracepoints.
This commit fixes the issue, so we can now do things like
`trace -K t:block:block_rq_complete`.

Making selection of kernel headers type automatic

Modern versions of USDT probes (such as what's found in
PostgreSQL when compiled with `--enable-dtrace`) may have
the offset listed after the global symbol for USDT
arguments of the format `4@symbol+8(%rip)`. This commit
extends the argument parser to support these cases, adds
tests for these cases, and makes sure that in case of a
parse error, the parser always moves forward and consumes
at least one character. Presently, the parser would get
stuck on the problematic position and enter an infinite
loop.

Add vxlan gbp header

* Filter by process ID in ex4slower

* Updated the rest of the tools to filter by process ID

argdist filter expressions can now use the STRCMP helper
function to compare strings. The first string must be a
compile-time constant literal string, and the second string
can be determined at runtime. This is a workaround until
BPF introduces a kernel builtin for strcmp.

Example:

```
argdist -H 'r:c:open(char *file):u64:$latency:STRCMP("test.txt",file)'
```

`trace` filters and print expressions can now use the
magic STRCMP helper function to compare strings. The first
string must be a compile-time constant literal string,
such as "test", and the second string can be determined at
runtime (e.g., from a function argument). The codegen for
STRCMP is on a case-by-case basis for each literal string,
and it generates an inline function with a constant-length
loop that compares the string's characters. This is a
decent workaround until we get something more reasonable
from the kernel side, such as a `bpf_strcmp` helper.

Usage example:

```
trace 'p:c:open (STRCMP("test.txt", arg1)) "%s", arg1'
``