Configuration refactor and clean-up. Some quasi-breaking changes 

Largely an internal refactoring of option/registry configuration that happens in extend and init. There are some external effects:

* Default data now resides on defaults (`Ractive.defaults.data` or `Component.defaults.data`)
* Options placed in the wrong place will not be picked up. Current behavior is more permissive in some regards.
* Plugin registries (`adaptors, components, decorators, easing, events, interpolators, partials, transitions`)
    * Will find entries up the view hierarchy if not found in the extend (inheritance) hierarchy, #646 now works as expected
    * Extend and init consistently. Including mixing and matching object literals and dynamic functions:
    ```js
    Ractive.defaults.partials.xyz = 'xyz'
    var Component = Ractive.extend({
        partials: function( partials, data ) {
            this._super( partials );
            if ( data.foo ) { partials.foo = 'foo' }
        }
    })
    var r = new Ractive({
        partials: { bar: 'bar' },
        data: { foo: true }
    })
    r.partials // 'xyz', 'bar', 'foo'
    ```
    Note the dynamic function signature has changed from my first go at this feature. Will write up documentation for this feature for 4.1
* In consolidating the template and partial parsing code, I noticed that template #element gets don't test for el being a `<script>`, but components and partials do check. For now, there is no check at all. But I think we should always only allow script tags across the board 

Internally
* `initialise` and `extend` are much leaner. The options are grouped under `src/config/options` by option. A configuration is ducked type to three methods: `extend`, `init`, and (optionally) `reset`. Most of the configurations use `baseConfiguration` as their base class.
* `src/config/config.js` is the master list of configurations and defines their order as well as provide access methods used elsewhere like `init` and `extend`. There is only one instance of config and each item config, I avoided the bloat of creating state for each ractive instance. A `_config` property has been added to each ractive instance and is used if a config option needs to store state between instantiation and reset. 
* Rather than doing multiple layers of option copying, the config items evaluated the values and combine or assign to the target Component or ractive instance.
* It used to be some options were copied to `ractive` instance, some were read from options. There are all (except `css` and parseOptions) now copied to `ractive` and used from there. The issue is that we now make only one pass and don't layer back onto options. So it's `ractive.noIntro` instead of `options.noIntro`. In theory, though we are not there yet, it moves towards ractive instances being maleable after instantiation.  parseOptions are kept on `defaults` during extension, and only kept on `ractive.parseOptions` after instantiation.

@Rich-Harris I had to wade through a lot of stuff, just let me know if I interpreted something wrong or you have other opinions about things.