If the process in question doesn't have the USDT probes we
expect, handle the failure gracefully. After all, it could
be a binary compiled without USDT support, the pid could be
recycled to some other application, or -- the process name
could match, but by accident, and really belong to some
other runtime.

The /proc/PID/cmdline file has \0 for spaces in the command
line, and there may be trailing \0 characters as well.
Replace them all with spaces.

This tool traces method executions and prints out messages
with a nesting depth indicator that allows relatively easy
visualization of program flow. To reduce overhead, `-C` and
`-M` switches take class and method prefixes to filter the
output by. The filtering takes place in the BPF program, so
the unnecessary data never ends up in user space.

Usage examples:

```
uflow java 185
uflow -M index python 180
uflow -C 'IRB::Irb' ruby 10041
```

This tool gathers statistics (by pid) on method calls,
class loads, garbage collections, thread creations, object
allocations, and exceptions raised and prints them in a
top-like style. Supported languages currently include
Java, Python, Ruby, and Node. Not all languages provide
the necessary probes for all event types.

Usage examples:

```
ustat -C
ustat -l java 1
ustat -l ruby -S objnew
```

Allow callers to obtain the list of active (enabled) USDT
probes from the USDT object, if they need to enable the
uprobes by hand without using the bcc attach support. This
is required when the same uprobe needs to be enabled in
more than one process.

Use various USDT probes in Java and Ruby, and `malloc()`
uprobe in C, to summarize object allocations by type or
by size. Print statistics at the end or at intervals, with
optional trimming of top types by number of instances
allocated or number of bytes.

Trace `pthread_start` calls and get the symbol for the
newly-started thread for printing. Also allow no-Java runs
with no language specified for pthread-only tracing.

`uthreads` attaches to thread start and stop USDT probes
and traces out thread creation and destruction events.
Currently, only Java is supported.

Add `-S` switch for tracing syscalls with or without high-
level language method calls. When `-S` is provided, attach
to all `sys_` and `SyS_` entry points in the kernel and
trace the number of calls and execution latency (if `-L`
was also specified).

This is now also a useful general-purpose tool for syscall
count/latency summarizing when a language is not specified.

Add Node support for gc__start and gc__done probes, which
includes GC type flag parsing.

Skeletons for method flow, object allocations, general
event statistics, and thread statistics.

For runtimes that make it available, we now extract GC
event information such as heap sizes and print this
information in addition to the GC duration and timestamp.

`ugc` monitors GC start and end events in Java, Python,
and Ruby, printing out a message when a GC cycle completes
along with the duration of the GC and an optional
additional description that depends on the target language.

NOTE: This WIP does not have any interesting additional
descriptions yet.

Usage example:

```
ugc java 1448	# monitor Java GCs in process 1448
```

`ucalls` is a new tool that uses the USDT probes in high-
level languages (Java, Python, Ruby) to summarize the
number of method calls and optionally their latency. This
is similar to `funccount` and `funclatency` but for methods
in Java, Python, Ruby, and other languages that might have
USDT probes for method entry and exit.

`ucalls` uses the `method__entry` and `method__return`
probes in Java and Ruby, and the `function__entry` and
`function__return` probes in Python. The Python probes are
not as accurate because they do not report the class name,
but are still useful.

The optional `-L` switch indicates whether latency numbers
are required. By default, only the number of calls to each
method is printed. The `-T` switch filters out the top
methods (by number of calls or total latency).

Add USDT support to C++ API

Improve linear histogram limit, and improve error message.

runqlen: use bpf_get_smp_processor_id()

add runqlen tool

check effective userid on run #850

add Quick Start Guide for bcc docker