* Eliminate rpmlint errors and allow bcc srpm to build on Fedora koji build system

The nightly bcc srpm does not build as-is on Fedora 24. To get the
build to work the following changes were made in the bcc.spec file:

-Specify where to find luajit headers and libraries
-Correctly limit the build to the x86_64 architecture
-Add needed build requires so the srpm can build on Fedora koji
-Run ldconfig so shared library information is updated
-Follow spec conventions by putting %changelog at the end of the spec file

* Further refine the bcc.spec file

Make the following improvements to the gcc.spec file:

-Use local_clang_static variable to allow building with locally installed clang
-Adjust build requires to include nucurses-devel and make
-Put the subpackage descriptions and file list in a more logical order
-Correct the binary rpm dependencies for the subpackages

Fixup test errors in clang, c api

Some errors seem to have cropped up due to updating kernels and clang
library versions.
1. test_c_api fails on kernels (seen on fedora 4.9) where startup_64
doesn't start at a particular address. Simplify the test to hopefully
work in more systems.
2. The lua and python test_clang did a dereference on a particular bio
field, which has been removed. Pick a different field that is more
uniquitous.
3. test_xlate1 was generating code where the verified pointer spilled.
Rewrite the example to store the result on the stack.
Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>

trace: Avoid passing -1 as the pid to USDT

When the `-p` switch is used with `trace`, it would set
the tgid to the value passed to `-p` and set the pid to
-1. The result would be incorrect logic that passed the -1
pid value to the `USDT` context constructor, which fails
for probes that require the pid to enable (because they
have a semaphore that needs a poke). This commit fixes it.

cc, python: Clean up BPF module and tables

When the `BPFModule` object is destroyed, shared tables
were closed, but non-shared tables were not. Add `close`
call to close non-shared tables in `~BPFModule`.

Make sure the `BPF.cleanup` function in the Python module
calls `bpf_module_destroy` to clean up the module. Otherwise,
we have hanging table fds that aren't destroyed.

Fixes #806. This would have been an issue for any tool
that repeatedly runs a BPF program with new maps. It's just
that most tools we have haven't exhibited this behavior.

Make bcc_symcache_new(tid) work with symbols from /tmp/perf-pid.map

Fix warnings covered by -Wdelete-non-virtual-dtor

The warnings were:

 src/cc/bcc_syms.cc: In function ‘void bcc_free_symcache(void*, int)’:
 src/cc/bcc_syms.cc:217:40: warning: deleting object of polymorphic class type ‘KSyms’
                            which has non-virtual destructor might cause undefined behaviour
                            [-Wdelete-non-virtual-dtor]
     delete static_cast<KSyms*>(symcache);
                                        ^
 src/cc/bcc_syms.cc:219:43: warning: deleting object of polymorphic class type ‘ProcSyms’
                            which has non-virtual destructor might cause undefined behaviour
                            [-Wdelete-non-virtual-dtor]
     delete static_cast<ProcSyms*>(symcache);
                                           ^

Fix the warnings by defining a virtual destructor for the base class SymbolCache.
Signed-off-by: Marco Leogrande <marcol@plumgrid.com>

* support filtering by process ID (-p) or thread ID (-t); previously -p
  actually filtered on thread ID (aka "pid" in kernel-speak)
* include process and thread ID in output
* flip order of user and kernel stacks to flow more naturally
* resolve symbols using process ID instead of thread ID so only one symbol
  cache is instantiated per process
* misc aesthetic fixes here and there

perf_reader: install perf_reader.h

Expose destruction of SymbolCache in libbcc

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.