Rethink hits report strategy

[MarcoRossignoli]

After a prolific talk with @jakubch1 we could try to change hits report strategy to solve mainly two issue:

1. On collectors side remove embedded coverlet code for in-process load inside vstest repo

Possible solution: we could change tracker to report hits in a shared memory open by out-of-proc data collector.

2. Be resilient in case of "fast kill" issue on msbuild driver https://github.com/tonerdo/coverlet/blob/master/Documentation/KnownIssues.md#1-vstest-stops-process-execution-earlydotnet-test

Possible solution: report hits directly to persisted memory-mapped file https://docs.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files

In past an attempt to use shared memory/memory mapped file(on flush not for every hit registration, so we need also to take care of performace against int array) with no luck due to special needs of System.Private.CoreLib #276 (comment), if we take this path maybe we need to avoid such dependency and wrap native api cross plat or simply give to user a way to chose which engine to use and so runtime repo can use current one that handle this special context.