Starting on solution for #44

Won't have time to finish this one right now, but this solution should work well.

1) Realized there was no reason to do the deferring thing, we just register immediately after
allocation and use that pointer, so got rid of some overhead in code/time on regular shared_ptr loads.
2) For cases with no default constructor the interface will be changing slightly.  Instead of having the
user do both the allocation and initialization, the user will only be responsible for the initialization.
This works as follows:

We allocate std::aligned_storage big enough for the type and pack it into a shared_ptr for the proper type with
a custom deleter to correctly call the proper destructors.  We'll wrap up this raw pointer in a new class called
cereal::allocation (or similar) which will now be passed along with the archive as a reference to the load and
allocate function.  The user now loads up their data as before using the archive, and then instead of performing
a raw call to operator new, they pass all of their arguments to the operator() of the cereal::allocation object
which then performs a placement new into the aligned_storage (transparent to the user).  Should resolve the circular
reference problem too.
progress towards circular loads #44

Passing tests but need to look over this with valgrind some more.  Potentially have some issues here, moreso with
unique_ptr than shared_ptr.
Also for #44, need to test type_traits on load_and_allocate
adding tests for load_and_allocate

relates #44
Considering #44 fixed

Need to do a once over on documentation to finish up, see issue #22
Adding access to members during allocate

Moving code around a bit, allocate is now in access.hpp which seems
to make a bit more sense.  Exception is now in helpers.hpp.

It is now possible to use a cereal::allocate<T> object to directly
access member variables or functions after it has been initialized.
Accessing them before initialization will throw as will performing
a double initialization.

see #46