[Review Only] Use CodeInspection API

This is based off of master, but includes `mark/fixes-linter-reporter` and `mark/dark-widget` because I wanted that code to be in here before I started work on the CodeInspection API changes.

This still works with the current CodeInspection API (adobe/brackets@2333b85790518b1b7b84b1511bd83f77375aed53)

I'll create a new PR once we merge both `mark/fixes-linter-reporter` and `mark/dark-widget` in some form into Interactive Linter, to make this have a less odd commit log.

**TODO/Notes:**
  - This does not underline in code, as Brackets doesn't provide a token, only the linter-reported start pos.
     - I don't know how feasible it would be to create tokens for (theoretically) any linter out there.
  - This PR takes the CodeInspection API `inspectFile` and then does all of our handling on the results.
  - The CodeInspection API does not put Synchronous linters into workers, so that is a theoretical performance regression.
  - This makes the linter panel a mix of custom/Brackets code, since I don't copy the CSS from Brackets for the lint panel.
  - We could use `inspectFile` once (probably in `setDocument`) and then pull the providers out of that, doing provider management ourselves.
    - If we did this, a fake file with the same path ending might be a good idea, as it would reduce time spent to get the provider results. This fake file would be empty in terms of contents.
  - (?) Don't disable the default JSLint of Brackets

**Regressions:**
  - Fatal error checking
     - TODO: Check if Brackets 'aborted' flag on results actually is used by lint provider extensions. If so, this is done.
  - Error vs. Warning messages (everything is marked as a warning)
      - Different linters/providers have different concepts. CodeInspection.Type is not enough; it isn't descriptive enough, nor does it seem to be used widely by provider extensions.
  - Better integration into the panel when only one linter is present
    - Make it display like Brackets does, where the panel title has the linter name and the errors are displayed without sectioning.
  - Anything else?

**What this deprecates:**
  - `pluginWorker.js`
  - `pluginLoader.js`
  - `pluginManager.js`
  - `linterSettings.js`
  - `plugins/*`

Note: I'll update this main comment as I think of new things, and mark things as `Resolved` when (and if?) they get resolved.
Cool, then we really don't need to call parseInt.  One thing that is really important in interactive linter to make sure we save every bit of extra processing, even if it does not seem to have a performance impact.