* Make ldd dependency detection only work on shared objects
Make it a noop on others?  Can't really gather any information
automatically.  One possibility for object files is to look
at the output of `objdump -t` to see which symbols are undefined
(and report those as warnings).

A good candidate for this is just `nm -u` to list undefined symbols
in an object file.  This could be used for static libraries, too.
(maybe readelf)

* Port all scheme code to Guile to remove the Ikarus dependency

* Copy base dependencies and scheme code to $PREFIX if necesary

* Clean up debugging output
The current debugging output is eclectic and only somewhat useful.
There is a great deal of room for improvement.  It also needs to
be split into per-analysis debugging.

* Make progress descriptions default to silent

* Refine ownership model
One low-hanging fruit is to determine which structure fields
are NEVER finalized.  This would allow us to not mark parent
pointers (and related constructs - such as externally-scoped
variables) as escaping.  There are likely plenty of other ways
to improve in this area, too.

* Re-implement weak fields
This is related to the previous item.  This used to work but
suffered some bit-rot.

* Remove the clang executable from the build step
clang is nicely split into reusable libraries; the analysis should
just embed these libraries and use them to perform the preliminary
type analysis as its first step.

* Normalize function parameter handling behind an iterator interface
LLVM presents ABI artifacts in its function signatures.  For example,
functions returning structures by value appear as void and have a
first parameter with a special annotation into which the return value
is written.  The code to work around all of these works, but is ugly
and should be factored out into something more intuitive and reusable.

* Forward-port to llvm-2.5 (maybe 2.6 by the time I get around to it)
This was released relatively recently and I haven't had a chance to
try this yet.  Changes should be minimal (the biggest issue will be
finding a Clang version that compiles against it).  There were some
changes regarding by-value parameter handling which might require some
changes to the analysis code.  This also might rely somewhat on the
previous item.

* Objective C support
This could be possible (just dynamically link the ObjC runtime
when loading a shared library), but the highly dynamic nature
would make analysis useless for most methods.

* C++ support
This would present some new research opportunities, but progress is
somewhat blocked on clang C++ support.  In theory, it would be possible
to use another program or library to recover the type information that
LLVM discards (unfortunately, the only real solutions there would
be gcc-xml, treehydra, or ROSE).  These extra dependencies are very
undesirable (not to mention huge).  This isn't critical enough to worry
about, and I am content to wait for clang.

Significant research possibilities:
 - Handling of virtual functions (this could degenerate to the function
   pointer problem - loaded plugins *could* add new classes/overrides).
 - Templates in public interfaces (this could *possibly* be partially
   addressed by creating explicit instantiations at analysis time for
   primitive types and the host language object type, e.g. PyObject).
 - Exception handling.  Each library could conceivably have its own
   exception type which would need to be trapped and converted.  Setting
   up a catch(...) could lose useful information.  Doing this portably
   might be very hard, if it is even possible.

* Allow paths (scheme libdir and dependency dir) to be specified in colon separated lists