Allow disabling cache

[angelikatyborska]

This allows to either set the command-line option --cache=false or add cache: false in package.json to disable caching, and change the cache's location with --cache-location="" or cacheLocation: "" in package.json.

The option in package.json takes precedence (because that's how it was already defined for the parser option).

Backstory:
We use semistandard at my job. Today one of our projects had suddenly failing builds on CI due to lint errors that did not appear on developers' machines. The cause was an update to semistandard that slightly changed linting rules. However, a simple rm -rf node_modules && npm install on developers' machines did not help reveal the issues. After some hair-pulling, we realized those new issues suddenly appear after an unrelated edit is made to a file. That lead to the discovery that ESLint is capable of caching (where it's disabled by default), and that this project hardcodes cache: true. We would like to disable caching in our project to minimalize the chance of discrepancy between linting results on developers' machines and CI as speed is not an issue in the project.

[Flet]

Sorry you ran into trouble :(

Ah interesting, so when semistandard was bumped to 12.0.0 it changed the way some existing rules were enforced to be a bit stricter, but the cache still existed from the previous version's runs. This meant that it didn't hit the new rules until one the previously cached file was modified...

This is definitely something we should keep in mind when we upgrade standard and semistandard. We should probably change the cache path or flush the cache somehow when folks upgrade to a new version.

For this PR, I'm a bit conflicted. I think the reason this happened was due to the out-of-date cache after upgrading. I've not heard of any other issues around file caching for existing versions.

If we can instead clear the cache automatically in new versions that could be a better solution. If not, maybe a --flush-cache option to clear the cache would be a simpler solution than having folks break out of the cache with new command line options.

@feross any thoughts?

[feross]

@Flet I agree with your assessment. These options will get exposed to end users of standard (and variants) and 99%+ of users should never need to use these options.

I just made a PR that includes the version in the cache folder name so that we reduce the likelihood of this (rare) issue: #181

[feross]

Superseded by #181