gh-838

This PR addresses the 'Attempted to remove a dependant that was no longer registered' errors. Mea culpa, predictably enough - one of the recent changes was to allow dependants to register themselves against multiple keypaths (i.e. evaluators and computed properties with multiple dependencies - previously, they would create 'satellite' dependants), but the viewmodel still treated `dependant.registered` as either `true` or `false`.

So an evaluator that depended on two keypaths, and unregistered from one of them, would cause an error when it tried to unregister from the second.

This is now fixed. It prompted a couple of other changes, e.g. in how two-way bindings come to be notified that their keypath has changed.

@martypdx I want to run a couple of the changes past you before merging, since I think some of the code affected was yours originally - will comment on the relevant lines
@martypdx this is the flip side of what I referred to below. You can end up in `mustache.resolve()` because of a section splice/merge causing indices to change, or because a [reference] expression resolver updated to point to a different keypath. In the first case, the children are already taken care of, but in the second they're not.

Now that `mustache.resolve()` *doesn't* cause rebinding to happen, it needs to happen as a direct consequence of the [reference] expression resolver updating the mustache.

Again, let me know if this looks sane to you...