Add support for dependencies

[russelldavis]

This allows you to specify an array of dependencies as part of any grunt task's files config. If any of the files in deps are newer than the dest (or the timestamp of the previous run, when there is no dest), all of the src files will be treated as new, and rebuilt.

As one example, this can be used to solve issue #18. The dependencies need to be specified in the config, so the full solution of calculating the dependencies based on @import statements would still need to be solved separately (although this could be used as a base for that -- you'd just need to dynamically set the deps config before running the task). But for tasks where the dependencies are known up front, this works great.

For example, say you have a single scss file main.scss that imports all the scss files under views. You could set this up with this simple config:

files: {
    src: ['main.scss']
    deps: ['views/*.scss']
    dest: 'main.css'
}

With this config, main.scss would be rebuilt any time any of views/*.scss changed.

There's also an option for global dependencies. This can be useful if, for example, you want to rebuild everything when the gruntfile itself changes. Just set newer: { options: { globalDeps: 'gruntfile.js'}} and that will work.

[tschaub]

This looks really promising @russelldavis. Thanks for coming up with a solution. I'll try to make time for a more careful review in the next day.

[tschaub]

@russelldavis apologies for letting this sit without comment for so long. I appreciate your work and like aspects of this solution, but I've got an alternative in mind.

Instead of requiring that people add configuration options to the 3rd party tasks (which could in theory cause issues), I'd like to support a general purpose option that would let people provide additional "dependencies" given a source file (that the newer task thinks is not newer). This would be in the form of a function with a signature like this:

getDependencies: function(taskName, targetName, sourcePath, callback) {
  // ...
}

[russelldavis]

Makes sense -- that works better for dynamic dependencies. I still like the idea of keeping the dependencies together with the files config for each task. I wonder if that would actually cause issues with any third party tasks in practice, but I understand the desire to play it safe.