Proposal for a serialization interface

[jeizenga]

Here's my proposal for a serialization/deserialization scheme.

I put it in a separate class for now, but I think the right way to do this is with one of @adamnovak 's HandleGraph traits. As such, I'm not going to bother working it into the class hierarchy. I also considered putting these methods in the base HandleGraph, but there are things like overlays that we don't care to have serialization methods for.

One thing I wish I could do here is to include a virtual constructor like:

class HandleGraph {
    virtual HandleGraph(std::istream& in) = 0;
};

Anyway, turns out virtual constructors prohibited in C++. I opted to have a deserialize method instead, but I don't love that this more or less requires you to first construct an empty graph and then deserialize in two distinct steps.

[jeizenga]

I guess we've given up on the idea of the template-based "trait menu" for handle graphs, so serialization won't end up being incorporated into that system. Taking that into account, I think this current factoring probably makes the most sense. I don't expect any algorithms to need a combination of other traits simultaneously with serialization, so we can have the implementations inherit serialization separately.

[ekg]

I like this way you've done it more than having a constructor. Nice.