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.
One idea I have been toying with is a top-level "languages" configuration option that would essentially set a bunch of other configuration for you.

The default would look like this and would come with your gulpfile.js
```js
var customizedOptions = {
    languages: ['javascript', 'typescript']
};
```
Within wGulp that would modify `taskTree` to include necessary build tasks for js and ts.

Then if a consumer wants to disable TypeScript (like I have them doing in this portion of documentation we are commenting on) they could modify it like so:

```js
var customizedOptions = {
    languages: ['javascript']
};
```
and it would essentially make the same changes to the `taskTree` that I have documented above.

We could also support `coffescript` and `livescript` as options in that list that would simply add `coffee` and `livescript` tasks to `taskTree.build`.