WIP: Initial implementation of channel-logs

A channel log is a persistent change list of a channel, stored in a
document. These are now used to generate the changes feed, instead of
the view. In some cases the view will still be necessary, because the
channel logs have limited length; that isn't implemented yet.
Improvements to sequence allocator and Tap feed observer.
Output conflicts in log-based changes feed.
Use "changes" view to fill in if the channel log is incomplete

If the channel log doesn't go back as far as the 'since' query param,
ChangesFeed() now runs a "changes" view query to get the earlier revs.

If the channel log is entirely missing, ChangesFeed() also rebuilds it
from the view output and saves the channel log. So it should be possible
to delete channel-log documents by hand to fix any corruption.
ChannelLog now tracks its 'since' sequence

ChannelLog is now a struct with a 'since' value that tracks what
sequence it's authoritative after. This lets us reduce the number of
sequences that have to be looked up from the "changes" view.
ChannelLog and changes feed now handle conflicts.
Cleanup

* Renamed ChannelLog --> ChangeLog
* ChangeLog.TruncateTo must now be explicitly called by clients.
  That way ChangeLog doesn't have to hardcode a limit.
* Improved comments.
ChannelLogs store revisions in order added (not sorted by sequence)
Use compound sequence IDs

Instead of sequence numbers, the _changes feed now uses compound IDs
that look like chan:##,chan:##… Basically, for each channel it lists
the last sequence number seen on that channel. (This isn't the same as
the _highest_ sequence number seen, since sequences might not be added
to a channel log in order. But knowing the last number seen tells the
changes feed where to start in the log next time.)
Public sequence IDs contain global last-sequence value

As an optimization, sequence IDs now contain an entry for channel "*"
whose value is (an approximation of) the database's last sequence number
overall. This allows the _changes feed implementation to quickly decide
there are no new changes.

This number appears in the sequence ID as the value of the channel "*".

Unfortunately it's tricky to determine the actual last sequence number
without running into race conditions, so the current implementation only
approximates it as the largest sequence number on a subscribed channel.
Hopefully this can be improved later on.
Revert "Public sequence IDs contain global last-sequence value"

This reverts commit 0071fd708df5126c07b516bd7d602d098ea4df0e.
Never create a channel-log doc for channel "*"

There would be too much contention because every write updates it.

This patch actually fixes a bug because "*" was only half-implemented:
the channel log would be written the first time the _changes feed asked
for "*", but it would never get updated on doc writes, so it would keep
returning the same stale data forever.
Now the "*" channel is always fetched from the view and never written
to a log. This is slow, but that's OK because this channel will only
rarely be used, probably for admin purposes.
Fixed #74: longpoll _changes feed never completes
Clean up updateDoc, and sequence of db changes

* Fixed the ordering of db changes made by the core db.updateDoc method.
  The user/role documents now have their cached channels invalidated
  AFTER the new document revision has been saved; this fixes a race
  condition.
* Multiple retries in updateDoc (if there are race conditions) no longer
  cause multiple sequence numbers to be generated.
* Refactored some Database methods into document.
* Added a way to get the IDs of all users/roles:
  DatabaseContext.AllPrincipalIDs.
* Added admin REST API to get list of users/roles (GET /db/users, etc.)
Update to newer revision of gomemcached (some bug fixes)
Fixed a newly-introduced race condition in updateDoc

If two tasks update a doc at the same time, one of them might acquire a
new sequence number first, but fail the race to save, and then store the
now-not-newest sequence number in the document. In this case, it will
now generate a new sequence number during the second attempt, rather
than store a lower value.

(Also added/improved some comments.)
Use new Bucket.WriteUpdate to fix race condition with access()

If a doc revision changes user access to a channel, the updateDoc
method saves the new access in the doc metadata and then updates the
user doc to clear the cached channel-access map.
The problem is, the next time the User object is loaded and it rebuilds
the access map, the document revision that triggered the change might
not be saved to disk yet, so the view results will be stale, causing
obsolete channel access to be stored.
This patch fixes this by using the Indexable mode of the new UpdateWrite
call to ensure that the new doc revision is indexable.
Oops: Admin GET /db/role was returning list of users, not roles
sync() fn can now assign users to roles

The sync() fn can now call role(username,rolename) to give a user a
role. (Actually either parameter may be an array, for multiple assign-
ments.)
Fixes #77
For consistency, role names in role() JS call must have prefix "role:"

Pretty sure this is the right thing to do, but it might be more trouble
than it's worth, in which case it's not hard to back out.