feffpath library is working

This is a very big pull request.  At this point, a stand-alone library for computing individual Feff paths is basically complete and functional. Among the features are:

1. An entry point that can be compiled against Fortran code, a wrapper for C that can be compiled agains C or C++ code, and bindings to the C library for python and perl have all been written and extensively tested.  To the best of my knowledge, everything works in all four languages.

2. Unit tests for the fortran code can now test also test the output of the python binding.  Unit tests exist for the perl and python bindings

3. The C wrapper and all parts of Feff have been tested for memory leaks and other problems using [Valgrind](http://valgrind.org/).  Fixing memory leaks in the C code is essential for language bindings to work correctly.  Any future changes to the C wrapper **must** be checked with Valgrind.

4. The unit tests now include fits to EXAFS data for several of the materials.

5. Many changes to the build system, including compiling everything as shared object libraries rather than static.

6. The struct in the C wrapper now captures almost all of the information contained in the header of the `feffNNNN.dat` file.  Basically, the struct now has almost every attribute of [Larch's _feffdat group](http://xraypy.github.io/xraylarch/xafs/feffpaths.html#the-feffdat-group-full-details-of-the-feff-dat-file).  This is passed along to the perl and python bindings.

7. The python binding is also a larch plugin.  The `setup.py` file is jiggered to install its three files in the system-wide larch folder (`/usr/local/share/larch` on linux) so Larch wakes up knowing how to do a `scatteringpath`.

There is still plenty to be done, but I think that the code is in a solid enough state that it merits making this pull request and giving anyone watching an opportunity to check out the progress I've made.

One final note for purist pythonistas: I use SWIG to build thin wrappers around the C library for use in python and perl.  I know that all the cool kids use ctypes.  I chose to go with SWIG because it was a bit easier and more robust (due to the complexity of the C struct) than the more native approach for perl.  Once I solved the problem of writing a highly functional perl module around the thin SWIG wrapper, it was relatively easy to use a similar strategy for the `scatteringpath.py` Larch plugin.  Basically, all the weirdness of the SWIG wrapper is hidden behind the Larchy goodness of the plugin (or the Moosey goodness of the perl module).  That said, I half expect that someone will eventually scrap my plugin in favor of one using ctypes.