Object-Oriented Geometric Intrinsics Refactorization + OpenCG Compatibility

This pull request provides a more flexible object-oriented implementation of geometric intrinsics, including ``Materials``, ``Surfaces``, ``Cells``, ``Universes`` and ``Lattices`` than that in the current release version of OpenMOC. This PR is a full departure from the original XML input specification originally used in OpenMOC prior to the current SWIG-generated Python interface. All of the example input files have been updated to reflect the changes made to the geometric intrinsics and are fully functional. The online documentation will be updated soon in another pull request to the ``gh-pages`` branch.

In particular, this refactorization of the geometric intrinsics no longer requires the user to  implicitly define the constructive solid geometry "tree" using the "IDs" of various object. Instead, geometric intrinsics are registered with each other to build up the CSG tree (*e.g.*, adding ``Surfaces`` to ``Cells``, adding ``Cells`` to ``Universes``, etc.). Furthermore, the ``Universes`` are now instantiated directly by the user as an object rather than implicitly defined with an ID given to each ``Cell``. This makes the Python input specification slightly more lengthy, but much more transparent and scalable to complex, large reactor geometries.

In addition, some additions were made to permit the user to extract geometric intrinsics from the CSG tree in Python using some SWIG magic. For example, users may now retrieve Python dictionaries of ``Cells``, ``Universes``, etc. using new routines, a subset of which are below:

* ``Geometry.getAllMaterials()``
* ``Universe.getAllCells()``
* ``Universe.getAllMaterials()``
* ``Universe.getAllUniverses()``
* ``Cell.getSurfaces()``
* ``Cell.getAllCells()``
* ``Cell.getAllUniverses()``

These are helper routines which traverse the CSG tree and return geometric intrinsics to the user in Python. The intrinsics can be modified by the user with the changes being directly reflected in the underlying ``Geometry``. This permits easy parametric optimization studies over various geometries and/or material compositions all from within Python.

This PR also implements a fully functional compatibility module with OpenCG ("Open Combinatorial Geometry"), a tool which will be made open source in the coming months. This is implemented in ``openmoc/compatible/opencg_compatible.py`` and is installed as the ``openmoc.compatible.opencg_compatible`` Python module. In particular, the compatibility module allows users  to build 3D reactor geometries in OpenCG and to easily export them to OpenMOC, and vice versa. This functionality is useful for V&V between reactor physics codes, parametric optimization studies over geometric parameters, etc. The compatiblity module is a corollary to the one currently being reviewed for release with OpenMC in this [pull request](https://github.com/mit-crpg/openmc/pull/331).

A final note is that ``Universe`` at the root node of the CSG tree is no longer required to have ``ID=0``. This constraint on the ID was simply a legacy requirement based on the original input XML specifications when they were modeled based on OpenMC. With this geometry refactorization, this constraint is no longer necessary since a user now "registers" the root node ``Universe`` object with the ``Geometry``.

Yeah, I am open to suggestions on how to best populate the ``Lattices`` with ``Universe`` pointers - the templates were just my best first effort to this end. I definitely hard-coded some items into these examples since at the time I just wanted to make sure the new ``Geometry`` would work properly. So if anyone thinks this can be better generalized let me know.

I'm not sure that I understand the point of using 0's in the template (instead of 1's in this case). What would this accomplish? I filled each template with the corresponding ID of ``Universe``. I do think that this is ugly and should be changed before merging this PR, but am unsure the best way to go about it.