Improve tests for ln -s with relative source arguments

[nfischer]

Also inspired by #833.

ln -s is weird in that the semantics differ depending on whether it's given a relative path or an absolute path. For example:

$ touch file.txt
$ mkdir dir/
$ # Create a link, with an absolute path
$ ln -s "$PWD/file.txt" absoluteLink # ./absoluteLink is non-broken
$ mv absoluteLink dir/ # ./dir/absoluteLink is still non-broken
$ # Create a link, with a relative path
$ ln -s ./file.txt relativeLink # ./relativeLink is currently non-broken
$ mv relativeLink dir/ # But now ./dir/relativeLink is broken

I think shelljs does the right thing, but I'm not sure if our tests obviously handle this.

We should also consider making this explicit, but adding a utility function like utils.symlinkIsBroken(pathToLink).

[nfischer]

Another thought regarding code coverage: how good is our coverage for other utilities handling broken links? For example, does rm('-r') do the right thing if there's a broken link in the folder? What about cp('some-real-file', 'broken-link')?

We might consider making a utility function called utils.createBrokenLink(), which creates a broken link and returns the name. Ideally, this should create the link in the tempdir (it probably needs an argument for that).