Fixes Issue and PR #93 - Subscription handling in route computations...

The following use cases must be handled when working with route computations in
the onRun method:

1) Old computation invalidated then new route is run before flush. For example,
the user writes this code:

Posts.update({...}); // invalidate the old computation
Router.go('/someOtherPath'); // go to new route

2) Subscribe to the same subscription between routes should not create a new
subscription.

3) Subscribe to a new subscription in a new route should stop the subscription
from the previous route.

4) New computations must not be stopped because we call stop on the previous
computation. In other words, the new computation must be

Solution Details:

We need to stop the previous computation and set up a new computation for the
new route. But the new computation must be set up before the next flush,
otherwise we'll lose out on Meteor's subscription optimization (don't create a
new subscription in a computation if that subscription has already been created
- e.g. from a previous route). But we also need to stop a subscription if a new
route doesn't re-run it.

Previously, I was setting up the new computation in a Deps.afterFlush callback.
This effectively created a new computation that wasn't stopped. However, it has
two problems. The first is that it bypasses Meteor's subscription logic, and
creates a new subscription no matter what, even if the previous subscription was
the same. The second problem is that there's no reason to wait for the next
flush before setting up the new route. This may have even been causing
performance problems.

What we should be doing is stopping the previous computation and putting the
function to set up the new computation in an onInvalidate callback. Here's how
it works:

A computation's onInvalidate callbacks get called in the current event loop tick
for one of two reasons:

1) the computation has been stopped
2) the computation has been invalidated

So when we call stop on the previous computation and then call
onInvalidate(maybeRunReactively), the maybeRunReactively function is run right
away, because the previous computation is stopped (which implies invalidated).
This also works if the previous computation is already invalidated. We'll call
stop on it anyway, and now it will be marked as invalidated AND stopped.