Specs and fixes for nested partials with relative paths problem

This fixes "File to import not found or unreadable" problem when there are several load paths, and imported partials use relative paths:
https://github.com/petebrowne/sprockets-sass/issues/27

I believe `context.root_path` is to blame:
https://github.com/petebrowne/sprockets-sass/blob/master/lib/sprockets/sass/importer.rb#L100
https://github.com/petebrowne/sprockets-sass/blob/master/lib/sprockets/sass/importer.rb#L63

There a two problems with that.

1) Once you start using several assets load paths, you essentially have several "roots" to build relative path from. 

For example, a file A in `assets/` imports a file B from `vendor/`. Now, if any @import directive in file B uses relative path, you would want to build this relative path from `vendor/`, but `context.root_path` points to `assets/`.

2) `Sprockets::Context#resolve()` treats relative paths starting with '.' or '..' as if they originated from `context.pathname.dirname` which is the actual directory where file A resides, not from `context.root_path`.
https://github.com/sstephenson/sprockets/blob/master/lib/sprockets/context.rb#L78

Current sprockets-sass code builds relative paths from `context.root_path`, which in case of file A in `assets/` and file B in `vendor/` come in form `../vendor/`. This works only when `context.pathname.dirname` and `context.root_path` are the same. I.e. if file A is at the topmost level in `assets/`. Placing it somewhere deeper, like in `assets/folder/`, breaks things.

My patch fixes these problems by finding appropriate root_path, so a relative path built from it is resolved properly by `Sprockets::Context#resolve()`.