Scoped inline partials and named yields - RFC

This attempts to address a handful of issues ( #583, #1317, #1429, #1173 ). It basically moves inline partial parsing to the conversion process instead of having a shotgun regex extraction before beginning conversion. After the template is parsed, the partial nodes are extracted from the template and attached to the parent nearest instance (base or component). This allows:

```html
{{>part1}}
<!-- {{>part1}} -->
  I am part1 in the base instance
<!-- {{/part1}} -->
<cmp>
  <!-- {{>part1}} -->
    I am part1 attached to this cmp
  <!-- {{/part1}} -->
</cmp>
```

`cmp` can have a template (or partials) include `{{>part1}}`, and the instance from the template will have its provided partial overridden with the inline partial. Partials can still be defined anywhere in the template, and they will still be stuck on their nearest Ractive parent.

### Named yields

Yielders get an extra conversion step, like partial context, that allows a name to be specified after `yield` e.g. `{{yield foo}}`. Instead of referencing a single `yieldTemplate` though, they reference either the root content of the component (internally represented as the name `''`) or an inline partial from the content of the component. Only inline partials from the component content can be referenced. The same rule of one yielder per component still applies, but it is expanded to one yielder per name per component.

```html
<cmp>
  base content
  <!-- {{>yieldMe}} -->
    I can be yielded
  <!-- {{/yieldMe}} -->
</cmp
```
```js
var cmp = Ractive.extend({
  template: '{{yield}} {{yield yieldMe}}'
});
// results in 'base content I can be yielded'
```

### Proposed extra section

The inline partial syntax is sometimes a little cumbersome. With the moving of the partial extraction process to be inline with the rest of parsing, an additional section could easily be introduced, since all it would need to do would be to drop the appropriate node in the template. Partial extraction and scoping would handle the rest. I like something like

```html
{{#block foo}}
  inline partial content as usual
{{/block}}
<!-- or -->
{{#yield foo}}
  the same
{{/yield}}
<!-- UPDATE -->
{{#partial foo}}
  bar
{{/partial}}
```

### Issues
* ~~There are no tests yet.~~
* ~~Only allows `{{ }}` and `[[ ]]` for inline partials definitions. This can be addressed. It is left out for now because I didn't want to create a regex for every parse attempt for partials.~~
* If there isn't a base instance with all necessary components in place passed to the parser, the components won't get their inline partials. I don't think components work if they aren't already available at fragment-making time anyway.
* Yielders and inline partials can be mixed within a component, which may be confusing. I see that flexibility as beneficial, though.
* The differences between partials and yielders has blurred in my head, so I'm not sure I haven't broken something terribly. The existing tests pass though.
@evs-chris should `inlinePartials` go below in ractiveOptions (versus userOptions)? Just merging this, so let me know...