Login hooks.

Adds `Accounts.validateLoginAttempt`, `Accounts.onLogin`, and
`Accounts.onLoginFailure`.

The process for logging in a user is consolidated in accounts-base,
which is now the only package which directly accesses login tokens in
the database.

All login methods now go through `Accounts._loginMethod`, which
ensures that exceptions are captured and login hooks are called in all
cases.

The callback hook implementation code from livedata is extracted into
an internal `callback-hook` package, where it can be used by accounts.
Merge remote-tracking branch 'upstream/devel' into login-hooks
Clone the attempt object passed to login hooks, so the original can't
be modified by hook callbacks.

Give the Hook constructor a named option to debug print and ignore
exceptions, as just passing in a string argument to do that wasn't
very clear.
Drop `knownUserId`.

This comes at the expense of the password login methods which now need
to explicitly return the user id with errors, but makes for a less
confusing flow of control.
Misc login hooks code review items
Be extra careful that password reset tokens are one-time use.
Fix call to Hook constructor in livedata
Merge remote-tracking branch 'origin/devel' into login-hooks
Add comment linking to hackpad.
Add history note.
minimongo: Save all array indices, not just first

This 'x' thing is a bit of a hack. The idea is that there are two
consumers of arrayIndices. One is '$', which only looks at the first
index. The other is (soon) sort ken generators, which cares if indices
are explicit or implicit, but doesn't really need to "parse"
arrayIndices; it just will use them to associate branches from different
lookup functions with the matching arrayIndices.  'x' is a simple way to
accomplish this, though I could have made the values of arrayIndices be
objects too.
Drop Sorter name and use _.extend for prototype

Should be a no-op.
Failing test-case for a sort bug
Key-based sort.

This rewrites the sorter to generate "keys" for each doc and find the
lexicographically minimum "key", rather than to look at each sort key
field separately.

This commit doesn't actually change the semantics (and the failing test
still fails) because the key generator actually still computes the full
cartesian product of all keys, rather than only using fields that are
next to each other in arrays.
Make sorter closer to Mongo sort key semantics

Specifically, this ensures that with sort specifier {'a.x': 1, 'a.y': 1},
{a: [{x: 0, y: 4}]} sorts before {a: [{x: 0, y: 5}, {x: 1, y: 3}]} by
ensuring that the latter only has sort keys [0,5] and [1,3], and not
[0,3].

It does this by ensuring that the different fields used to generate a
sort key are only matched up if they use the same "path" (series of
array indices used during lookup).  This is a little stronger than what
MongoDB does: MongoDB lets you do {'a.x': 1, 'a.y.z': 1} where 'a' and
'a.y' are both arrays, and our new rule requires all fields to have
either the exact same set of arrays or to use no arrays at all.

(MongoDB does still have some constraints; eg, with sort key {a: 1,
b:1}, a and b cannot both be arrays.  Basically, there may be at most
one "outermost" array across all the fields; and so on recursively, sort
of.

The previously failing test passes now.
a more direct _generateKeysFromDoc unit test
Fix non-array fields with array fields
more _generateKeysFromDoc unit tests
Add tests for "index parallel arrays" error
expand a comment, as suggested by code review