Add Logging

[Siphonophora]

In any case, it seems like we should probably pull the logger from this and get the mstest fix released?

+1 to separating the logger. I think the logger may be a higher priority need since it is impacting your productivity (let me know if I got the priority order incorrect). Let's get that released right away. Two thoughts on the logger:

1. Could we expose logger as part of ITestRun e.g. ITestRun.IDebugLogger? It will be available to most of the workflows, and if needed we can pass the reference to data structures like TestResultInfo. This will help inject a testable/noop logger for unit tests.
2. Instead of exposing a key specific to our TestLoggers, can we depend on the test platform trace infra? See https://github.com/microsoft/vstest-docs/blob/main/docs/diagnose.md#collect-traces-using-command-line and the way to use it will be to use EqtTrace.* methods in our IDebugLogger implementation. See https://github.com/microsoft/vstest/blob/main/src/Microsoft.TestPlatform.CoreUtilities/Tracing/EqtTrace.cs#L24. All logs will get written into the log.txt we provide while invoking dotnet test.

I'm curious if the debugging TestLogger will be solved if we include the symbols together with nuget package (portable symbols or otherwise), that will enable stepping into code just like we could do earlier with JunitTestLogger itself. What do you think?

Originally posted by @codito in #21 (comment)

[Siphonophora]

I thought I had replied a while ago.

1. I'm fine with putting the logger on the interfaces instead of having it static.
2. This sounds good too.

Because we are usually having mstest run the loggers, I'm not sure if the pdb would help. At least, I'm not sure how we would attach a debugger to that process, so we could step through it.

[codito]

Created #23 for the embedded symbols and source code. It should allow us to step through the Testlogger APIs in debugger without cloning repo, doing a debug build etc.