Log event for slow glob evaluation so VS can alert users

[Pilchie]

We've seen several reports from customers where glob evaluation has severely affected VS performance:

1. One customer with ~600 projects and ~200,000 files had a glob in a targets file imported by all projects that looked for files from the root, accounting for 6s out of a total of 8s of evaluation time while loading the solution.
2. It's not uncommon for internal customers to have globs that are rooted by an env var - then when they open in VS without that env var set, the evaluation end up being rooted at \ and takes forever.

We discussed mitigations for this, and it would be nice if MSBuild could log an event once evaluation has takes more than a certain threshold (ideally including which glob it was and where it was rooted). Then VS could hook that up to a perf tip.

[Pilchie]

Options considered:

a. Specific logging of globs and if it goes over a certain threshold (or always? too much overhead)
b. Can we remember that evaluation was slow and turn on the evaluation profiler the second time?
c. Turn on profiling by defualt in a low-overhead mode which times every operation, but only records the info if it's over a certain amount of time. Can we do this in a low-enough overhead fashion?

We picked a, because we suspect that globs will be by far the most likely offender.

[danmoseley]

BTW @rainersigwald is there an issue to have MSBuild take advantage of the faster file enumeration .API's shipping in .NET Core 2.1 ?

[rainersigwald]

@cdmihai ^ do we have a bug for that? I know you worked on the design . . .

[rokonec]

@JanKrivanek please consider for analyzers.