Initial support for concatenated archives, and memory fixes

This branch does the following...

### Memory management fixes ###
Fixes some memory management issues. Currently cereal has a mixture of strings handled with `std::string` and strings handled with `char*`. The use of raw-pointers leads to some counter-intuitive behaviour. For example:

```cpp
if (foo) {
  const std::string s("test");
  a.setNextName(s.c_str());
}
```

Typically the caller would expect this to work, because setNextName would take a copy of the string - but it doesn't. Therefore, in this case there will be a memory error after `s` goes out of scope. The first 5 patches address this issue by replacing some of cereal's raw pointers with `std::string`s.

### Support for concatenated archives ###
The JSON and XML input archives currently read in the whole of an input stream until they hit the end of the file. In some cases this is undesirable. For example a file may contain more data after an archive, or it may be received via some kind of socket stream, or via a UNIX pipe. In these cases it is incorrect to read to the end of the file. The correct behavior is to read to the end of the XML or JSON document.

This branch addresses this issue by adding a test case to show this issue. It writes two archives into a single stream, then checks that they are both read out correctly.

Following the test case, I have modified `XMLInputArchive` to add support.

Currently if two XML archives are written to an output stream the following output will be generated:
```xml
<?xml version="1.0" encoding="utf-8"?>
<cereal>
        <value0>Apples

Pears</value0>
</cereal>

<?xml version="1.0" encoding="utf-8"?>
<cereal>
        <value0>Oranges

Lemons</value0>
</cereal>

```
Here we are outputting one archive with the string `Apples\n\nPears` and another with the string `Oranges\n\nLemons`. cereal's XML output will insert an empty new-line after each XML document.

Currently RapidXML does not provide a mechanism by which it can read only up to the end of the document, so my modification reads until it finds an empty line, then attempts to parse the accumulated XML. If the parse fails, this indicates that we have hit an empty line inside the XML document and the we should continue reading. The drawback of this approach is that the document must be re-parsed every time the input stream emits a blank line, which might become problematic in an XML document containing many empty lines.

There is still some work remaining to fix `JSONInputArchive` similarly to pass the test. It may be possible to do this via RapidJSON's internal stream support, or by counting the the number of `{` and `}` braces, until the tally returns to zero.