libpyne

This PR makes our C/C++ library a first class citizen following [these suggestions](http://lucumr.pocoo.org/2013/8/18/beautiful-native-libraries/).

This basically entails a complete refactor of the C++ side of the build system.  This has the following features:

* a single `libpyne` that you can link against
* a single `pyne.h` that can be included via `#include "pyne/pyne.h"`

Other features such as those implemented by FindPyne.cmake have all been maintained.  

Testing this feature likely involves blowing away the existing install dir as it is incompatible with the develop install.  I anticipate that this feature will be useful to folks like @makeclean.

For background, I need to do something similar for bright and figured that I'd practice on pyne :)
SGTM


On Sat, Jun 14, 2014 at 2:57 PM, Anthony Scopatz <notifications@github.com>
wrote:

> In cpp/pyne.h:
>
> > -  #define isnan(x) __isnand((double)x)
> > +#ifndef PYNE_IS_AMALGAMATED
> > +#include <json/json-forwards.h>
> > +#include <json/json.h>
> > +//#include "dagmc_bridge.h"  // figure this out later...
> > +#include "data.h"
> > +#include "enrichment_cascade.h"
> > +#include "enrichment.h"
> > +#include "enrichment_symbolic.h"
> > +#include "extra_types.h"
> > +#include "h5wrap.h"
> > +#include "material.h"
> > +#include "nucname.h"
> > +#include "rxname.h"
> > +#include "tally.h"
> > +#include "utils.h"
>
> I would welcome this kind of change in the future in both cyclus and pyne.
> Furthermore, I don't feel that custom compiler and linker flags is an
> overly burdensome and is a pretty common thing to require. Also, I feel
> that this PR is valuable enough in its current state and that this
> shouldn't block. Relative to what you have to do to use pyne from C++ now,
> this is a huge leap forward.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/pyne/pyne/pull/472/files#r13782547>.
>