Add serialization example (WIP) to Readme

Fix typo in Readme
Add json::null_t type
Add json::basic_string<A> interface

Yes, a custom string type is being implemented. Here is why:

 * We don't want our strings to be mutable. String modifications should occur
   within the user's applications, and only when they are finished do they move
   into the json API.
 * Due to the recursive nature of the json::value type, the smaller the
   string, the better usage of memory we will have. For 64-bit systems
   this is a large win, though it appears a small victory at first.
   However, our custom string keeps the json::value type down to 24
   bytes instead of 32, and this is a win, as each json::object
   allocates a json::value and a json::string per entry. It would then
   be best to save memory where we can. While this comes at the cost of
   limiting a json::string's maximum size to a 4GB string, hopefully
   someone would have the common sense to not have object keys or actual
   strings larger than 4GB. (Famous last words). Regardless, we want a
   smaller string size, even if it means giving up the small string
   optimization (Perhaps at a later time the small string optimization
   will be used)
 * People like to chain lookups on a json::object, so having a
   json::string's hash value precalculated (and stored) within the
   string can save some calculation time (especially if performing a
   seeded probe). Since we're not constructing json::string's all
   that often, and using an extremely speedy 32-bit hash for a 32-bit
   string, that will be stored into a sparse array bucket (the
   json::object will be like the google sparse hash map), probing can be
   that much faster. Of course this can cause problems with the
   core::string_ref type being used, but it shouldn't be much of a problem.

While one might argue that these issues are premature optimizations, the
goal for MNMLSTC JSON is to have a minimal effect on memory consumption,
and to not cause huge unnecessary amounts of memory fragmentation
(though this is inevitable)