This will be used by `vue-jest` and potentially other projects, to write
a Jest transform that can adequately mimic `sass-loader`'s behaviour.

Closes webpack-contrib#873

As discussed in code review, this is more the responsibility of the
consumer, as `sass-loader/dist/utils.js` already exports all the
necessary functionality.

We can reduce our API surface slightly by not considering
`getSassImplementation` as a public function, and instead using to
determine defaults from within the only public function in `utils.js`:
`getWebpackResolver()`.

Because `getWebpackResolver` is now part of `utils.js`' public API, we
should test it separately so that we have some protection against its
API changing drastically from potential future refactors.

Using `getSassImplementation()` inside the resolver factory is not a
good idea not only because it means it will be called twice for normal
usage of the loader, but also because consumers of `getWebpackResolver`
are almost certainly also calling Sass itself, meaning they'll need to
use `getSassImplementation()` anyway to make sure they're using the same
implementation as the resolver thinks is being used.