[Async DB] Documentation/minor tweaks

I'm adding documentation, making minor tweaks as I'm reading through the code. Some of the changes are likely unnecessary/incorrect as I may be overlooking some finer aspects of the new code.

Let me know if I should continue with this or not.

I just started, so I plan to push more as I go through the code (planning to get through all the data code this weekend). I try to make sure nothing breaks, but I also haven't tested this code yet.

(I see you addressed the comments I made, so I'll have to rebase this anyway)
> You know better than me what these relationships are used for, but I imagine that this is mostly meant for the "Related" tab (but it got utilized for other things).

It's the reverse, actually. In the client we've always tracked related items in a separate table, the poorly named ```itemSeeAlso```. On the server, we now store those as ```dc:relation``` relations instead. That's actually the most wasteful at the moment, since for now those are always just other items in the same library (hence two itemIDs in ```itemSeeAlso```), but the idea is that eventually we'll support unidirectional, semantic relations with more meaningful predicates.

With cross-library copying, a URI makes some degree of sense, because it can actually be either collections or items (hence dataObject.js) and you have to identify the library and key for both.

Item merges are same library, so for those we could just store the old item key, but documents use URIs anyway, so it works decently well to just search for the provided URI with the right predicate.

The larger issue is that using relations for all of these is a way to simplify the API. It's easier just to give certain predicates special meaning then to add API support for cross-library drags and item merges and possibly other things in the future. But we could perhaps use a more efficient format both internally and externally, with an ```itemRelations``` table with just ```itemID```/```predicate```/```object``` (with a foreign-key constraint on ```itemID```). We could also perhaps offer the ability to use just a key for same-library objects. We'd need a ```collectionRelations``` as well, though I'm not sure if there could be any collection relations other than cross-library drags. This is assuming other tpy. The ```relations``` table is obviously designed to allow arbitrary relations as first-class objects in the library, but it'd be a lot more efficient if we could just make them item/collection properties.

There's a lot more here, though. There are user-specified relations (and how you enter those, choose predicates, etc.), but also custom item types and fields. The latter isn't a perfect fit for this, but when you get into issues of data exchange using RDF starts to make sense. But then with RDF you have a whole directed graph, which is way more complicated than we want to get into.

This is all somewhat separate from the original issue, but let's start with this...