Task Dependency Tree (replace runSequence)

## Preface

wGulp currently uses the `runSequence` approach to define what `build`, `test`, `dist` and the default task do. `runSequence` will run tasks in serial, which means it doesn't take advantage of gulp's ability to parallelize tasks as much as possible. 

It will also run tasks more than once if nested `runSequence` calls include the same task. This happens by default when you simply run `gulp`, for example. That will run `test` and `dist`, each of those specify `build`. So `build` ends up getting run twice.

In order to reduce task duplication and increase speed of tasks, we should use gulp how it was intended to be used instead of relying on `runSequence`.

## Proposed Solution

Instead of defining `build_tasks`, `test_tasks`, etc. arrays in gulp's config, this PR introduces a `taskTree` option. Every task supplied by wGulp has an entry in this tree/object with its value being that tasks' dependencies.

This is what the default `taskTree` looks like _(trimmed, see full tree in diff)_: 
```json
"taskTree": {
    ...
    "build": ["clean", "lint", "tsd", "jsx", "tsc", "copy:html", "copy:js", "sass"],
    "bundle": ["clean", "build"],
    "default": ["clean", "build", "test", "analyze", "jsdoc", "dist"],
    "dist": ["clean", "build", "minify", "bundle", "library_dist"],
    "preTest": ["build", "tsc:test", "copy:jstest"],
    "test": ["preTest", "karma"],
    "test:jasmine": ["preTest", "jasmine"]
},
```

Gulp will use orchestrator to determine which order to execute tasks in and parallelize them as much as possible automatically.


### Other benefits
A secondary goal of this change was to make it easier to add or remove one or two things from the default task lists. I've included optional/additional `taskTree` syntax for that. The following is an excerpt from the README (included in this PR):

----------------
You can override any portion of the tree to alter which tasks cause other tasks to run. Say you want to add a task called `myCustomTask` to build. You can simply copy the array from above and add it:

```js
taskTree: {
    build: ['clean', 'lint', 'tsd', 'jsx', 'tsc', 'copy:html', 'copy:js', 'sass', 'myCustomTask'],
    ...
}
```

But that gets pretty verbose. Because of that annoyance we offer alternative syntax for including and excluding tasks from the default dependency arrays.

```js
taskTree: {
    build: {
        include: ['myCustomTask']
    }
    ...
}
```

The object form of this configuration accepts the `include` and `exclude` keys as arrays.
Here are some more examples of this kind of configuration:

##### Not a TypeScript project?
Then you may want to exclude the TypeScript specific tasks:

```js
taskTree: {
    build: {
        exclude: ['tsd', 'tsc']
    },
    preTest: {
        exclude: ['tsc:test']
    }
    ...
}
```

----------------

## Testing

This needs to be tested in a variety of projects and ensure tasks are producing the correct output to verify that the default `taskTree` is correct.
after some more thought, i'm reversing myself.  orchestrator will squash the duplication already so there won't be a functional change resulting from removing `clean` from these tasks, but it would be best not to force people to be aware of the intricacies of the cascade when defining their dependencies.