Xdmf::New()

After some discussion with several interested parties, we've decided to re-work Xdmf a bit. Most of the changes involve the API, particularly moving to smart pointers and a more full featured and customizable API for producing Xdmf in parallel.

The existing XML format will most likely stay the same with a few additions. So if you're currently producing Xdmf data outside the API this will have minimal impact. Also if you're just reading Xdmf as a file format this will have minimal impact as well.

Smart Pointers

 Smart pointers in C++ will help eliminate memory leaks and double free problems.
 Most likely the implementation will be intrusive smart pointers with reference counting.
 It is expected that moving to smart pointers will have minimal effect on performance while
 greatly increasing the efficiency of resource management.

API changes/additions for sharing and producing data in parallel

  While reading Xdmf is well defined and straight forward in the current API, producing and sharing
  the underlying geometric and computed data can become complex (particularly in a parallel computation).
  Since there can be several ways to represent the same data (a single large uniform grid, collections, etc.)
  it is best to allow the application to determine the proper representation and the most efficient method to
  achieve the result (generate the heavy data and collect the associated XML). What is needed is a more flexible 
  mechanism.

  Will Dicharry (Stellar Science Ltd Co) has proposed an API that looks very promising. If you'd like to take a look, the code is available at:
  [1]

Remove libxml2 dependencies from base objects - use containers

  Currently, Xdmf is tightly tied to libxml2, actually using the library to store state information. This leads to
  instances where data in the Xdmf objects can become out of sync with the data in the XML representation in libxml2.
  A better approach is probably to let the Xdmf objects store all necessary data internally using C++ containers and 
  decouple the generation of the XML using a visitor pattern. This would also allow for various other representations
  of the light data as they become necessary. 

Better Fortran Support

  Xdmf is currently 'C'-centric in that array dimensions are assumed to be row-major and data is accessed in that fashion.
  To properly use Xdmf with arrays in Fortran, which is column-major, the arrays need to be transposed on one end or the other.
  Transposing in memory may not work for huge arrays and transposing during I/O may incur significant overhead. At very least 
  there should be transposing support with options.

Additional Topology Support

  Additional Topology types

Static Geometry, Dynamic Attribute Support

Much more testing, example code, and example datasets