Reimplement parallelism internal logic

[arturbosch]

From the changelog:

- `parallel=true` and `--parallel` now effect both the compilation and analysis phase. 
- Users of Gradle's `--parallel` flag are encouraged to turn off the parallelism of detekt. Or turn it on otherwise.
- detekt does not use the `ForkJoinPool.commonPool()` anymore internally. When embedding detekt feel free to pass your own `ExecutionService` to the `ProcessingSettings`.

Benchmarks:
detekt's parallelism is notated as p=false|true, gradles parallelism is notated as --p=false|true

Gradle Plugin run on detekt's codebase, ~40k lines:
1.1 clean buid --p=false p=false | 2.38s, 2.27s
1.2 clean build --p=false p=false | 2.30s, 2.25s

1.1 clean build --p=true p=false | 1.55s, 1.46s
1.1 clean build --p=true p=true | 1.53s, 1.47s
1.2 clean build --p=true p=false | 1.48s, 1.46s
1.2 clean build --p=true p=true | 1.46s, 1.45s

CLI on detekt's codebase, ~40k lines:
1.1 p=false | ~4.14
1.2 p=false | ~4.17
1.1 p=true | ~2.85
1.2 p=true | ~2.80

Conclusion:
There are no real performance benefits for a middle large project like detekt.
However there still could be some benefits for really large multi module Gradle projects when using Gradle's --parallel and using detekt's parallel=false.
Imo the code looks cleaner now and there is the possibility now to just use one thread.
We also do not use the CommonThreadPool and do not make him starve.

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@a367813). Click here to learn what that means.
The diff coverage is 50%.

@@            Coverage Diff            @@
##             master    #1991   +/-   ##
=========================================
  Coverage          ?   80.39%           
  Complexity        ?     1990           
=========================================
  Files             ?      329           
  Lines             ?     5610           
  Branches          ?     1025           
=========================================
  Hits              ?     4510           
  Misses            ?      554           
  Partials          ?      546

Impacted Files	Coverage Δ	Complexity Δ
...in/kotlin/io/gitlab/arturbosch/detekt/core/Junk.kt	76.92% <ø> (ø)	0 <0> (?)
.../kotlin/io/gitlab/arturbosch/detekt/cli/CliArgs.kt	92.59% <ø> (ø)	6 <0> (?)
...itlab/arturbosch/detekt/core/ProcessingSettings.kt	77.77% <100%> (ø)	16 <2> (?)
.../io/gitlab/arturbosch/detekt/cli/runners/Runner.kt	88.88% <100%> (ø)	5 <1> (?)
.../arturbosch/detekt/cli/runners/SingleRuleRunner.kt	86.11% <100%> (ø)	6 <0> (?)
...otlin/io/gitlab/arturbosch/detekt/core/TaskPool.kt	33.33% <33.33%> (ø)	3 <3> (?)
...io/gitlab/arturbosch/detekt/core/KtTreeCompiler.kt	48% <33.33%> (ø)	8 <3> (?)
...otlin/io/gitlab/arturbosch/detekt/core/Detektor.kt	50% <36.66%> (ø)	5 <3> (?)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a367813...01d16dc. Read the comment docs.

[schalkms]

Can we even test this with unit or integration tests?