First draft

Actually it's more of a first draft of a first draft. I'll keep updating the pull request until there's a proper first draft. The beginning, in particular, is quite choppy and decrepit. The middle isn't that great either. But the end is pretty good... right up until you fall off the page. 
Thanks for the suggestions! 

I typically encourage others to start by describing the problem they're trying to solve, so that's definitely advice that resonates with me. I was trying something new here by starting with an ultra-minimal example and building up to something usable -- ideally showing that 10 lines of code is enough to have something that very loosely resembles a graph db, and then working up to 500 lines. The idea being that at each step we'll highlight an issue with the existing implementation, then show a way to fix it. This means backtracking some, especially early on, but will hopefully highlight the way real development often occurs. 

Maybe I'll also do the same thing with a problem, introducing one early on that we can solve easily but then continue expanding the scope. It will probably be number-based, since those are simpler in micro-examples. Then switch and start riding the hobby horse around here. 

Re C), I actually meant you run out of memory not because the graph has gotten too large (this is an in-memory db, after all), but rather because the query results get too large -- eager queries can easily suck up N*N space, where N is the total number of vertices in the graph. I'll rewrite this to explain that better and walk through an example of egregious behavior.

I can try doing a little of D in the intro, with the toy problem, and then do more at the end once we understand graph databases better. One of the defining properties of graph dbs is their "index-free adjacency", which I'm saving as a surprise to the performance section at the end -- once that's covered it makes a very strong argument for our choice of database style, but even without that factor the queries we'd like to perform are much more straightforward in the graph style (and also often have better performance even without the later enhancements).