Make loadPath relative to gulpfile cwd

This is in response to #75 (and similar).

It makes all paths passed to loadPath relative to procDir, which brings the behaviour of gulp-ruby-sass more in line with sass itself.

In the latest version, you either have to add all the sass files that your sass files @import to the .src glob (meaning you have to specify them twice - once in the glob, once in the sass) or you have to use absolute paths in loadPath, which is not really viable in codebases that are cloned across multiple machines.

The expected behaviour in the sass tool itself is that load_paths [defaults to the working directory](http://sass-lang.com/documentation/file.SASS_REFERENCE.html#load_paths-option).

I realise this changes the behaviour of the option, not sure if that's too much. I'd find this very useful though, so I thought I'd suggest it and see what you thought.
If using loadpath breaks sourcemaps then that's a clear problem and a good reason against a default one as things stand, for sure. 

In more general terms, it seems really important to me that the interface on plugins is consistent. Both sass and gulp (insofar as I've used them both) transform only the files they're passed to work on, and they expect that the files will manage their own dependencies. In my experience of gulp, it's not common practise to glob support files — I kind of expect all files in the glob to be transformed unless I explicitly remove or filter them out, which would not be the case here. 

It's quite possible I've not understood this fully :wink:, I totally grant that. Are there any other plugins that expect you pass a glob of support files along with the target files (that is, files which themselves are not targets for transformation)? Browserify, for example, doesn't. I'd imagine they're fairly common companions — doesn't it feel weird that they expect completely different types of `.src` blobs?

I think this is the key thing, for me. I understand @robwierzbowski, that you don't want to hide the streaming nature of gulp and I'm with you, but up to a point — it feels to me like it's breaking something useful when that results in a plugin with an interface that differs significantly from both other, similar plugins, and the software the plugin is plugging in, too (if it doesn't, then I don't have much of a point). 

On this, I'm with @dopry — the value of gulp imo is the speed and code style, the streams are the means, not the point. If you're plugging in something that means working with streams becomes fiddly, to my mind it's better to finagle that behind the scenes, so that the i/o paradigm stays in tact.

I think that's my take. 

Also, by way of genuine question, what would the benefit of the plugin be over simply spawning sass, if you have to specify dependencies twice, that kind of thing? I kind of took the benefits of plugins over simply spawning processes to be fitting with ecosystem neatly? Again, I totally acknowledge that there's a lot I don't know about the finer details here, I'd be genuinely interested to know.