Optimized reader

This implements an optimized C++ reader for Amber topology files, which parses Amber prmtop files ca. 3x to 5x faster than the pure Python solution.  File parsing had become the bottleneck.  It is still slower than cpptraj's parsing routines, though (and, likewise, sander's and pmemd's), since this parser was designed to read _every_ section of the prmtop and interpret -- very generally -- and support all data types, etc.

Also, unlike cpptraj and sander/pmemd, this parser makes _no_ assumption about how many data elements are present in each section (which means every line has to be checked for new section delimiters (e.g., `%FLAG`, `%FORMAT`, `%COMMENT`, etc.), which substantially slows down parsing.  Furthermore, we make no assumptions about what kind of data type each flag is going to have, and we store everything in hash tables (`map` in C++ and `dict` in Python).

All prmtop flags whose Fortran formats we can understand (i.e., very simple) are used to determine the data type, which is stored in a `vector<ParmDataType>`, where `ParmDataType` is a `union` of a `double`, `int`, and `char[4]`.  Unrecognized formats have their lines saved and dispatched back to Python land to be interpreted there, since it is simpler to do so with Python.

Some timings on my MBP (2.6 GHz i5, 16 GB RAM, SSD) on a 2M atom system (prmtop was almost 400 MB):

Parser | Time (s)
----------|-----------
Pure Python | 53.2 s.
C++ optimized | 13.5 s
cpptraj | 7.5 s

So for this file, the new parser is 4x faster than Pure python, and less than 2x slower than cpptraj (not bad!).

If for whatever reason the optimized parser cannot be imported -- like if users don't have the Python headers installed and don't want to bother -- ParmEd will resort to the original Python parser instead.

Also, parsing old-style topology files is not supported by the C++ parser (but will still work -- it just runs in pure Python), so the parsing time for those files is not affected.