expand the notion of how we ignore symbols.

there are some symbols we want to ignore that do not include "@@"
in them.  for now, we just use a hardcoded list of these
symbols... maybe we want to do something more exhaustive in the
future.
move 'symbols' to 'globals.symbols' in command.

and access/set it intelligently / in a centralized manner.  we
started using the commands.go functions outside of commands.go.
they should probably be separated out and go into some utility
"library" (at least a different file) so that commands.go can stay
just actual commands.  but i digress...
bfd: fix find_symbol to actually/properly return nil.
command/symbol list: skip blank symbols earlier.
bfd: change 'needed' to be library-level, not symbol-level.

There are too many cases where we need the symbol and we can't
know until someone tests with a given program, otherwise.

The issue is that we need to get pretty exact functions from
find_function in the case that we have detected an access.  This
is because we need to filter accesses: not all accesses give us
information, and, worse, we can't build a control flow graph for
e.g. 'calloc', because DynInst reads the data from the executable
file, not the process' memory.

Thus we need to check to see if the access is in a
cannot-and-should-not-build-CFG function and explicitly skip it.
If we're missing symbols, we won't (accurately) identify what
function we are in, and will mess up that identification.

Right now, our ID is based purely on a hardcoded list of functions
that I noticed applications hit but are not actually relevant for
access.  This is a terrible way to do it.
avoid double-register-grab in segfault debug message.

'where' grabs the iptr, but we were already doing that; might as
well just do this directly.  also make our debug message better.
Follow unconditional jumps through memory references, too.