Option to rate limit linter calls

[HybridEidolon]

Some linters are implemented such that they parse the output of a build system rather than running a program against a single file, for example the Rust linter. As such, saving two files in quick succession can cause multiple instances of the build system to run, resulting in a lot of undefined behavior, unless the linter itself implements rate limiting. An option in a linter's class to only allow one lint to run at any time in a given Atom window would prevent scenarios where linting fails due to concurrently running builds.

A reason for having a common option for this is that the same behavior would be implemented multiple times across linters for different languages even though it is common between them. If the linter itself implements rate-limiting, the lints after the first lint would probably have to abort, resulting in unfinished linting (its correctness depending on the timing in which the lints were run and files were saved. Groan, concurrency!).

This option might override "lint on the fly" due to the implication that lints are potentially long-running, but this depends on the build system being leveraged; again with the rust example, it is possible to make cargo and rustc run without code translation, but only for the current crate.

Related issue: AtomLinter/linter-rust#29

[steelbrain]

Providers can just disable lintOnFly and they will only be triggered on save. That's the most efficient way for now. but I am not convinced that we need something on top of that.

[steelbrain]

You can find a demo of this in dartlang-tools and the dart lang package by the google team.