Adds fixer outcomes to reporting

[NickSdot]

Edit: As discussed some commits were back ported to other branches. This one now also contains more than the title suggests. While implementing the reporting I realised what the architectural weakness of the old shape was. Hence this here now also refactors the runner/processor story to a shape that doesn't squeeze fixers and reporting into the existing sniffer only structure.

---

Console, JSON, perf now report fixes; Checkstyle unchanged.

Depends on #29, #30, #31, #32, #33, #34, #35, #36, #37, #38, #39 and #40.
This PRs diff will shrink as preceding PRs are merged and this branch is rebased.

Diff against previous branch: NickSdot:stack-09-performance...NickSdot:stack-10-reporting (different to diff in here only until the previous branch was merged)

Console Output

OK -- 1 file(s) scanned, no violations remaining.
Total runtime: 2.000s
FIXING
----------------------------------------
Files changed 1
Fixes applied 2
Fixes skipped 0
Fixing passes 1
PERFORMANCE
-----------------------------------------------------------------------------
Sniffing Fixing
DocbookCS.Simpara 1.000s ( 50.0%) 0.500s ( 25.0%)
DocbookCS.ExceptionName 0.250s ( 12.5%)

[jordikroon]

When I run --fix --perf during a clean run, I get the following results:

REMAINING 35 violation(s) (35 error(s), 0 warning(s)) in 35 file(s).
Total runtime: 14.703s
FIXING
----------------------------------------
Files changed 9879
Fixes applied 44790
Fixes skipped 0
Fixing passes 9879
PERFORMANCE
-----------------------------------------------------------------------------
Sniffing Fixing
DocbookCS.Simpara 1.821s ( 12.4%) 0.055s ( 0.4%)
DocbookCS.MixedIndentation 1.349s ( 9.2%) 0.000s ( 0.0%)
DocbookCS.TrailingWhitespace 1.284s ( 8.7%) 0.007s ( 0.0%)
DocbookCS.AttributeOrder 1.233s ( 8.4%) 0.014s ( 0.1%)
DocbookCS.ExceptionName 0.453s ( 3.1%) 0.002s ( 0.0%)

When I run this command again, FIXING disappears. I would expect that it would still show, but skipped to be equal to the applied fixes from the previous run.

I personally think having just this is sufficient. It also makes more sense to have the fixer report above the remaining line.

FIXED 44790 violation(s) (44790 error(s), 0 warning(s)) in 9879 file(s).
REMAINING 35 violation(s) (35 error(s), 0 warning(s)) in 35 file(s).
Total runtime: 13.244s

[NickSdot]

but skipped to be equal to the applied fixes from the previous run

It cannot report no longer existing violations as fixed; the second run evaluates the already fixed source.

I personally think having just this is sufficient. It also makes more sense to have the fixer report above the remaining line.

Sure, I can change the formatting. But please note that:

1. files changes and fixing passes are not equal; one file can have multiple passes
2. to get the exact output you want (with error/warning) we would to carry over the violation level

Do you want that? Or is the goal to have current output sensibly in one line?

[jordikroon]

Just having it on a single line above the Remaining is sufficient.

Whatever it may include according to the needs. But the result would be that we first report what's done, then what still needs to be done.

[NickSdot]

Done. Ready for review...

Just having it on a single line above the Remaining is sufficient.

Violations with remaining

FIXED 5 violations [3 errors, 2 warnings] in 2 files (3 passes).
REMAINING 2 violations [1 error, 1 warning] in 2 files.
Total runtime: 2.000s

none remaining.

FIXED 2 violations [2 errors, 0 warnings] in 1 file, no violations remaining.
Total runtime: 2.000s

sniff mode

FOUND 2 violations [1 error, 1 warning] in 1 file.
Total runtime: 2.000s