Separate virtual DOM initialisation from rendering

This is a fairly substantial pull request - many files have been added and deleted, and many others have been changed. For that reason it's blocking other work from getting done (at least without storing up merge conflict headaches) so I'm going to merge it straight in.

The tl;dr is that *creating* the virtual DOM is now a completely separate process from *rendering* it. This makes the code easier to work with and easier to profile. It should make new features simpler to add, and opens the door for features that were previously nigh on impossible.

There are a couple of spots that still need a bit of tidying up, but that shouldn't get in the way of bug fixes etc.

A few more details about code changes:

* The 'render' folder (now 'virtualdom') used to contain two subfolders - 'DomFragment' and 'StringFragment' (the naming of these always felt a bit weird - naming things is hard). There's now just 'Fragment', which combines the two. A fragment contains zero or more *items* (text nodes, elements, interpolators, partials etc) which may themselves contain fragments. Each item now has a `render()` and `unrender()` method, separating out the work previously done upon initialisation and in `teardown()` (which is now purely responsible for unregistering dependants from the viewmodel).
* `reassign()` has now been renamed `rebind()`. I think it makes more sense.
* ES6 syntax is now supported (not just modules). At present there's a bunch of arrow functions and a rest parameter, but we can use anything supported by [es6-transpiler](https://github.com/termi/es6-transpiler#supported). (Some stuff looks pretty ugly once transpiled to ES5 - we should be discerning about which features we adopt. Arrow functions are a good example because they are very easy to transpile and improve code readability quite a bit.)

@martypdx one of the things I stumbled over a bit was getting `resetTemplate()` to work - the knock-on effects of separating initialisation from rendering included breaking some of that method's assumptions. To cut a long story short I came to think that it should be a synchronous method - it turns out to be a bit simpler that way (even if there are complex outro and intro transitions, there's no ambiguity about exactly when the result of a `ractive.get()` or `ractive.find()` call will change), and puts the control in developers' hands (e.g. you could unrender with transitions disabled, update the template synchronously, then re-enable transitions and render it). Can go into more detail about my thought process but wondered what you thought since you implemented it?