funccount, funclatency, stackcount user symbols don't work for containerized processes

All of these tools accept a symbol regex, which means they try to resolve the binary in which the symbol(s) may reside, and then try find all matching symbols (this happens before calling the actual attach API). There are two problems:

* The `BPF.find_library` helper doesn't take the target PID into account, so it passes pid 0 to `bcc_procutils_which_so`, which means it doesn't use the logic for looking into /proc/PID/maps to find the library path. (Which would be in the container's mount namespace, but still.)

* The underlying APIs for enumerating symbols (`bcc_foreach_function_symbol`) doesn't enter the container's mount namespace, so it fails to enumerate anything.

Just to clarify with a couple of examples:

```
# funccount jvm:*AllocTracer* -p $(pidof java) # java is running in a container
unable to find library jvm # caused by not looking in /proc/PID/maps to find libjvm.so path

# funccount c:open -p $(pidof java)
could not determine address of symbol open

# funccount c:*open* -p $(pidof java)
could not determine address of symbol _IO_file_fopen
```

Start with the funccount, funclatency, and stackcount symbol-resolution paths, then read BPF.find_library, bcc_procutils_which_so, and bcc_foreach_function_symbol. Reproduce the reported commands against a containerized Java process and trace how its PID and mount namespace are handled. Done means symbol regexes resolve libraries and symbols for containerized processes.

Written by the indexing model from the issue text.