Minor refactoring and bug fixes

Full title: Minor refactoring and bug fixes: windows end lines, findFileResults cache, export.done

Reason for every line change (the new line numbers are used):
(79) home is undefined (forward referenced) at this point so to improve clarity and maintain functionality I returned undefined.
(85) moved home down in the event it isn't needed
(167) path.join includes path.normalize
(177) moved parent down in the event it isn't needed
(183-184) fixed this oversight in caching, previously if not found it would only cache "C:\file", instead of every step, which wouldn't save much time.
(191-193) added js doc for 2 parameters
(203) the exclude file may now use any type of end lines
(221-278) renamed variables to be more meaningful
(278, 295, 360, 378) fixed bug in pattern: windows uses \r\n also compacted regex
(552-560) added the ability to clear the cache. the tests need to use this now that the cache was corrected
(575-579) force the result of loadIgnores to be mapped, previously only opts.ignores was mapped
(724) passed == null is the same as !passed (any falsy value) thus making the ternary that follows redundant. I don't know the possible values of passed

Concerns:
On line 79 I assume you meant to return null instead of undefined but I'm not sure so I kept the same functionality.
I didn't write a unit test for the end lines and I don't know how well supported the different end lines are.

Currently (master bc6e97e) loadIgnores uses "\n" which is just wrong but works by coincidence on windows machines because it trims every line thus removing the trailing \r. Of course it works fine on Unix but fails to split entirely on old Mac. If loadIgnores used the current regex it would split \r\n into 2 lines then remove blank lines thus also working by coincidence.
Likewise the currently extract also works by coincidence, \r\n becomes 2 different elements in the array which are later destroyed by using join("") (empty string).
However extractOffsets uses the array length and therefore returns a different answer. The problems are: I don't know what this is supposed to do and there are no tests for it. Based on the doc, given this:

<html>
<title>Hello World</title>
<script type='text/javascript'>  alert('Hello World');
</script>
</html>

I would think html line 3 column 33 is mapped to js line 1 column 3.
So I would expect the returned [null, null, 30, 0, null] array to be mapped like this:

<html>  //null
<title>Hello World</title>  //null
<script type='text/javascript'>  alert('Hello World');",  //30
</script>  //0
</html>  //null

So that: jsColumn = htmlColumn - map[htmlLine]
and: jsLine = map.slice(0, htmlLine).filter(function(value){return value === null;}).length  //counts # of preceding null lines

However when I ran this (using Unix line endings so that the either regex would do the same thing) I got: [null, null, null, 3, 3]
Which I thought would map like this:

<html>  //null
<title>Hello World</title>  //null
<script type='text/javascript'>  alert('Hello World');",  //null
</script>  //3
</html>  //3

but that doesn't make any sense. So what is this function supposed to do? What should be returned and why? How is it used?
I'll try to look into it when I have time but an answer would tell me what it should be doing instead of what it is doing.