AMIL currently has a single index, mapping object IDs to nodes. Object
IDs are taken to be unique, and that is enforced on the server, but we
take the ID from the client, which is not generally scalable. In
addition, the single namespace for all nodes, when we want to have
human-readable names at least for demo purposes, is far too limiting.

The following scheme is proposed:
- AMIL will have a notion of "projects". This is a second-class class
  of objects: only nodes and links are first-class, but the AMIL
  implementation will provide direct support for these, as described
  below.
- Each project will have a notion of "versions", though we're waving
  our hands over some of the difficult parts of that. Again, these are
  supported by the AMIL implementation.

Projects have names that are unique *within the namespace of
projects*. Versions have two names: one is unique across all versions,
and the other unique across the associated project. All nodes
(including nodes describing projects and versions, if they exist) have
an associated project and version. This is unlikely to be an explicit
link (too much crud in the database), but is handled either by system
attributes on each object or simply by appropriate index entries. If
the mapping from project/version to node is handled by indexing, it
becomes possible to copy a subgraph between projects or versions
simply by performaning an index manipulation, if we either can enforce
that the subgraph is read-only, or have decent ways to handle changes
so they don't propagate.

The old OBJECT_ID field for nodes will be a triple (probably just one
string, though), derived from project, version, and version-unique
name (generated by the server). Nodes may also have a "nickname" which
must be unique within the version.

In normal operation, one sets a  context on one's connection
indicating the project/version pair to use. This allows nicknames to
continue working as they do now, since they're still unique within
that context. The context is managed primarily on the client side, and
passed as part of the request as needed.

This requires several indices to be managed, rather than the single
OBJECT_ID index we have now:
One maps from class and GUID to node:
"Project"/PROJECT-NAME: Project node
"Version"/VERSION_GUID: Version node
"Node"/NODE_GUID: Node

One lets us find all the nodes in a version.
PROJECT-NAME/VERSION-NAME: node in project/version pair

One lets us find version GUIDs:
PROJECT-NAME/VERSION-NAME: Version GUID (could also be just in version
node, which this would refer to)

One lets us find nodes by nickname easily:
Version GUID/Nickname: Node

There may be a new AmilLib API to pass the context for certain calls
(esp. loading in bulk, getting all nodes, etc.), but in general the
context will be stored in the AmilLib by a single call, and passed
with all subsequent calls.

Not sure what to do if it's not set (sometimes it's clear, sometimes
not).