Source Sampling

This PR adds a C++ class which allows for Monte Carlo source sampling of a particle source distribution defined on a MOAB mesh. This can be done using either analog or biased sampling schemes. A uniform (biased) sampling scheme is implemented natively within the class and the class can sample a user-supplied biased source distribution (e.g. one produced using the CADIS method). Both Cartesian and tetrahedral meshes are fully supported. A full explanation of this is provided in the source_sampling.h doc strings and also the theory manual.

Although this is  a huge refactor from the version I used for the RPSD paper, none of the core methodology has changed. 

The ```Sampler``` class is no longer a singleton, however, I have not implemented a Fortran interface yet. I plan to do this by passing pointers (in the form of unsigned ints) from C++ to Fortran (the advice of @gonuke). That will be my next PR (this one is big enough!).
> This is one of the fundamental concepts of object-oriented design and supports separation of concerns.

Hi @gonuke - Only as implemented in mid-level languages (such as C++ and Java).  Both lower level languages and higher level languages do not typically have strict access control. While I personally feel that access control is a bad idea, that isn't sufficient to disallow it here.  

The justification for disallowing access control in pyne is that it does not play nice with other languages. In generally hurts interop.  From the higher-level language standpoint, it is incredibly frustrating to have fields on an object which are only partially visible or mutable. Knowing that there is something out there that cannot be changed by a user in any way is a disempowering experience. A much discussed example of this is the timezone support on the datetime object in Python. Though this was written in C (not C++), the partial exposure up to Python is eternally frustrating and has the same effect as a private member. We want our users to walk away feeling happy not frustrated.

On the lower level language side of things, the use of private members means that you build only partial interfaces to other languages (C, Fortran). It possible to do this right - I think MOAB does an exceptional job here. It is also possible to do this very wrong. The C bindings to clang (libclang) are horrible because they are only partially implemented.  

I believe the writing code without access restrictions leads to better interop with most of the the rest of the world, which doesn't have this language feature.  Since pyne is meant as canonical forms + glue code, I think that this is the right thing to do to encouraging playing nicely with others. Finally, note that the style guide says:

    We are all adults here. Everything should be public. Use private and protected variables only 
    when absolutely necessary.

This means that private and protected variables are OK as long as a justification is provided that there is no way that these members can or should ever be part of the API.  They are truly for internal use only.  My several cents :).