Viewmodel

The purpose of this PR is to start moving the guts of Ractive's data binding code into a dedicated `Viewmodel` class. At the moment, some of this code is slightly hard to follow, especially for potential new contributors. Encapsulating it this way should make it easier to reason about, document and maintain, and may reveal opportunities to do certain things in a smarter way.

In the longer term, it may be possible to extract the viewmodel code out into a completely consumer-agnostic module (think Ractive without templates - a way to manage reactive data flow within an app without having to go all RxJS pointy-headed). That's not the immediate goal though.

In contrast with the last big refactor (#696) I'm hoping to do this in smaller stages, so that it's a bit more obvious what's going on, and it doesn't just result in bugs being introduced. So this is likely the first of several PRs. While it looks fairly major (11 commits, 73 files changes) it's actually not - some modules have been moved about, some objects now belong to other things (e.g. `ractive._cache` is now `ractive.viewmodel.cache`), but none of the underlying mechanisms have changed. Subsequent PRs will be less conservative.

@martypdx One thing I haven't yet figured out is quite how the config refactoring affects all this. At the moment each `Viewmodel` instance [stores a reference](https://github.com/ractivejs/ractive/blob/3fda706dd5f7d8f7e7ac9ca8e3e2b13fc0222766/src/Ractive/initialise.js#L12) to its parent `Ractive` instance *before* `config.init()`, because that's [necessary](https://github.com/ractivejs/ractive/blob/3fda706dd5f7d8f7e7ac9ca8e3e2b13fc0222766/src/config/options/computed.js) for computed properties to work. Then, it uses that reference to find e.g. `ractive.data`. Do you reckon that `config.init()` should initialise the viewmodel 'directly', so it has its own reference to `this.data`? (Similarly for `ractive.adapt`.)