Adding LOC count for August, 2014

Also updated the script to support Octave 3.8.0
casting a negative number to an unsigned int caused badness here, it seems the - 18 magic number can cause some issues depending on parsed_libmesh_configure_info[0].size().  Since std::setw() seems to want an int, cast instead to an int and let it handle the negative as before.
avoid std::cout << unsigned char problem
eigen 3.2.1->3.2.2
Merge pull request #336 from libMesh/eigen_3.2.2_refresh

eigen 3.2.1->3.2.2
rbOOmit change. Added RBEvaluation::read_in_vectors_from_multiple_files, which
allows us to read in vectors from multiple files without renumbering the mesh
dofs on each read.
Adding Rabiti, 2014
Update traffic
Adding Howard Hinnant's unique_ptr implementation.

Ultimately I decided to install unique_ptr.hpp alongside the libmesh
headers, similarly to nanoflann.hpp, since trying to include it with
our Boost seemed like it would be difficult to make work with external
Boost installations.

This required several items:
* Updating test_boost.cc
* Updating Boost README instructions
* Adding boost header files required by Howard Hinnant's unique_ptr
  implementation to our local copy of boost.  Most compilers I tested
  required the same boost subset except for Intel 12.1, which also
  required boost/mpl/aux_/preprocessed/plain/and.hpp
* Updating Boost's Makefile.am
* Updating boost.m4 so libmesh can use unique_ptr.hpp
  ** Use $top_srcdir instead of $srcdir
  ** When using libmesh's boost distribution, add it to
     libmesh_contrib_INCLUDES.  This way, it can be used while building
     tests and examples.
  ** Adding $(libmesh_contrib_INCLUDES) to AM_CPPFLAGS in
     examples/Make.common
  ** Require at least Boost 1.55.0, since that is what we distribute with
     libmesh.
  ** BOOST_CPPFLAGS is not valid for libmesh's internal Boost headers
     If we use the Boost headers distributed by libmesh, the include path gets

     -I../contrib/boost/include

     a relative PATH which isn't valid when used with e.g. libmesh-config
     --include.  This hasn't caused any errors that I know of, but it isn't
     right so we should probably remove it.
* Creating the contrib/unique_ptr directory:
  ** Create contrib/unique_ptr/Makefile.am from scratch, copying from nanoflann's.
  ** Adding an AC_CONFIG_FILES line in libmesh_optional_packages.m4 for the new
     Makefile.am to get automake to see it.
  ** Update the include/libmesh/rebuild_makefile.sh script by hand to include the
     unique_ptr.hpp header.
  ** Updating include/libmeshMakefile.am file by running the script.
  ** Running bootstrap.
Adding a configure test for Hinnant's unique_ptr.

This involved several steps:
* Use the new AM_CONDITIONAL in appropriate Makefile.ams
* Allow user to explicitly disable with --disable-hinnant-unique-ptr
* Add conditional installation flags for Howard Hinnant's unique_ptr
  to script which builds Makefile.ams
* Regenerate Makefile.am using said script
* Adding a libmesh_config #define for Howard Hinnant's unique_ptr
* Main difficulty is getting the right CXXFLAGS while using either an
  external Boost or libmesh's Boost.
Ran bootstrap
Adding AutoPtr as preprocessor macro, fixing invalid AutoPtr use in library and examples.

C++11 supports alias declarations which would make this a bit more elegant, viz

  #ifdef LIBMESH_HAVE_CXX11_UNIQUE_PTR
    template <typename T>
    using AutoPtr = std::unique_ptr<T>;
  #elif LIBMESH_HAVE_HINNANT_UNIQUE_PTR
    template <typename T>
    using AutoPtr = std::boost_ptr<T>;
  #endif

but we can't require this capability in the library yet.

The following invalid uses of unique_ptr-based AutoPtr are fixed in library and examples:

1.) The copy constructor is explicitly disallowed by this new AutoPtr.
    The kludge once required for ancient xlC compilers:

    AutoPtr<X> ap(new X);
    return ap;

    is replaced by

    return AutoPtr<X>(new X);

    Note that we have not been consistent in using this kludge for a while
    now (see various Elem::build_edge() implementations) and no one has
    complained...

2.) It is ambiguous to construct a std::unique_ptr with an explicit (NULL) argument.
    This is apparently because there is a 'nullptr' constructor for this
    class.  Luckily, using the default constructor instead works just fine.