fixes #1482

This addresses a bug identified in #1482, whereby mustaches on one side of an unresolved component mapping wouldn't update immediately when the mapping was resolved.

@martypdx @evs-chris I haven't quite got my head round the mapping changes yet, so I'd be grateful for a sanity check...
Right, sure thing. 
* With computed properties, mappings can be reversed (see [init of Viewmodel](https://github.com/ractivejs/ractive/blob/dev/src/viewmodel/prototype/init.js#L16)).
* (The end of the above method tracks reversed mappings, so they can also be reverted because mappings aren't strictly hierarchical and the child component's viewmodel [can be torndown](https://github.com/ractivejs/ractive/blob/dev/src/viewmodel/prototype/teardown.js#L9-L11)) 
* Because of this, mappings check (line 80 above) to see if dependents have already registered with the viewmodel by calling unregister _without a dependent parameter specified_. That calls new functionality to [bulk unregister](https://github.com/ractivejs/ractive/blob/dev/src/viewmodel/prototype/unregister.js#L39) in the viewmodel unregister method.

Concretely: you have a `{{foo}}` reference in a parent view that creates a child component with a computed property `bar` mapped to `foo`, `<child bar='{{foo}}'/>`. So the original interpolator needs to be unregistered from the parent view and registered to use the mapping.

Now, I don't totally understand the condition under which this is occurring in the original issue. So I'm not entirely clear if the same thing could happened for these transferred mappings. But it seems they could end up in same unresolved state and perhaps then should have `setValue` called? Or would they not have a been registered???