Passed ctest (MPI and nonMPI) excluding ADIOS1 engine, and Python bindings
HDF5, C bindings and C++ tests working
Introduced BeginStep EndStep functions
Renamed IO GetVariable/Attribute to InquireVariable/Attribute

Implemented basic buffer reading functionality
Added threading for bp serialization/deserialization
Refactored MPI functionality
Engine is now a reference
Initial Read API

Added portable PathSeparator
Fixed format for bp file name

Bugs: 1) Missing binary mode in FilePointer fopen and FStream ofstream
transports
      2) Replacing reinterpret_cast of size_t to uint_64, not the same
on Windows 64-bit

Removed some warnings generated by Visual Studio

Added static_cast for type conversions

Refactor XML reader to restore original check on single engine
conditions and eliminate warnings. Test added.

Allow ctime and fopen "not secure" warnings: now using binary fstream as
default file IO library on Windows

Increased Default Maximum Memory to 200Mb
Added config.xml for the heat transfer example for memory management
(among other parameters) at runtime 

To do:
Copy config.xml to /build/bin, right now the heat transfer example won't
run in config.xml is not found

Checking std::ios_base::failure exceptions
IOChrono is off by default, each owner turns it on explicitly
Modified FileDescriptor and FilePointer destructors
Added Tests BPWriteRead for stdio and fstream
Removed IO AddTransport with vector (shoud have been there?) to enable
AddTransport in Tests

Added example bpFlushWriter (incomplete).

bool flag checks are implicit
Removed single letter enums in ADIOSTypes.h
All enums are enum class in ADIOSTypes.h using CamelCase
ADIOS uses delegating constructor
Using return type of emplace for IO (in ADIOS) and Variable (in IO)
Removed all base class include from inl template file

1 Now IO (replaced Method) and is the factory for Variables and Engines
2 Reduced core components to user-public objects only
3 Moved and reorganized all helper functions to helper directory
4 Engines are now lightweight (except for ADIOS1Reader WIP) using MACRO
5 HF5Common and ADIOS1Common (except for Readers WIP) are now part of the toolkit so they can be reused by Engines
6 TransportMan is a new layer for transport management (file is default)
7 DataMan will be implemented under toolkit/transportman/dataman
8 Template separation (tcc and inl) applied all over the code
9 Improved Doxygen documentation

Runtime Issues:
DataMan library compilation (cacheman)
ADIOS1 Warning
TestADIOSInterfaceWrite catches exceptions

Some code for joined array reading in adios1 engine, incomplete. Rather should support it in adios1 itself.
Committed only to have a working Write/Read API so that we can have examples with global arrays finalized.

- Added examples/groupless/multistep writer example to the build
- Added ADIOS1 reader but it does not work yet
- Added heat transfer example reader

This will allow for generic template functions that can deal with
complex types using thier underlying value types.  So rather than have:

template<T> T foo(const T&);
template<T> T foo(const std::complex<T>&);

to handle the case where an std::complex<float> should use a float
return value, you can now use a single signature:

template<T> TypeInfo<T>::ValueType foo(const T&);

The type traits will be useful for maping ambiguous C types to fixed
width integer types used for the actual I/O operations, for instance:

  adios::TypeInfo<char>::IOType resolves to int8_t
  adios::TypeInfo<signed char>::IOType resolves to int8_t
  adios::TypeInfo<unsigned signed char>::IOType resolves to uint8_t
  adios::TypeInfo<long int>::IOType resolves to int64_t
  adios::TypeInfo<long long int>::IOType resolves to int64_t

So in this case, even though char and signed char are "the same", they
are distinctly separate types to the compiler.  Using
adios::TyperInfo<T>::IOType you can use the same fundamental type for all
of them.  Similarly for long int and long long int.

This allows us to both drop the namespace prefix when using them in
implementation and guarantee that we don't use versions of the types
that get re-defined elsewhere.

In order to provide the least ammount of disruption this doesn't include
any sweeping search and replace changes.  However, it is recommended
moving forward that these types be used internally when fixed width
sizes are expected.  This will allow the transition to happen gradually
through attrition and minimize conflicts.