Add System.Private.CoreLib support

[pjanotti]

This is a special case needed to make coverlet the official code coverage tool on CoreFx repo (see https://github.com/dotnet/corefx/issues/31281).

The change didn't cause any noticeable performance penalty and basically has a custom "metada importer processor" to deal with System.Private.CoreLib.

[codecov]

Codecov Report

Merging #209 into master will decrease coverage by 0.11%.
The diff coverage is 90.9%.

@@            Coverage Diff             @@
##           master     #209      +/-   ##
==========================================
- Coverage   95.03%   94.91%   -0.12%     
==========================================
  Files          15       15              
  Lines        1590     1633      +43     
==========================================
+ Hits         1511     1550      +39     
- Misses         79       83       +4

Impacted Files	Coverage Δ
src/coverlet.core/Instrumentation/Instrumenter.cs	98.92% <90.9%> (-1.08%)	⬇️

---

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 967c180...e808d16. Read the comment docs.

[pjanotti]

😃 nice report! I can't actually test this e2e (requires a copy IL of System.Private.CoreLib and then running the instrumented version). However, I can add a test to cover the type added to the code by faking a dll as being named System.Private.CoreLib...

[tonerdo]

@pjanotti don't worry about the coverage result right now. I don't enforce a threshold and 94% is still pretty good! Will review this PR over the weekend

[ViktorHofer]

@tonerdo have you had time to look into the changes? We really would like to use them in corefx as soon as possible :)

[tonerdo]

@ViktorHofer will take a look later today. Been busy attending to some personal affairs

[tonerdo]

@pjanotti apologies for taking so long to get to this. I've looked through it and nothing jumps out at me. However, I'm a bit concerned that we have to create a provision for this in the core library. But looking at it again I feel I can make this single allowance since it's for an integral part of .NET Core.

Out of curiosity why didn't #181 fix dotnet/corefx#31281?

[pjanotti]

Good question @tonerdo: the issue is that System.Private.CoreLib can't reference any external assembly and the tracker template is injected, intentionally, by referencing netstandard. This allows it (at least in theory) to instrument assemblies running against any runtime that supports netstandard. All the code used by the tracker template is part of System.Private.CoreLib so what this change does is that it ensures that no actual reference is made via netstandard.

Unfortunately I didn't see a way to avoid this special case. That said it in principle can be used against any "corlib" that can't reference external assemblies (as long as the "corlib" contains the types used by the tracker template).

[tonerdo]

Thanks for this @pjanotti, will make a new release tomorrow and notify you once that happens