[WIP] Add project result elements to XML

[CharliePoole]

This will fix #53 but is currently partial only.

One thing leads to another! Currently, everything seems to be working correctly except for when you use `--process:Separate. When that happens with one or more projects in the command-line, the whole job of figuring out the proper hierarchy falls to the agent process. This is more work than the Process Runner and agent process were originally designed to handle so changes will be needed.

I see some choices for this issue...

1. Merge what's done and leave the --process:Separate case for fixing later. (3 PRs)
2. Put this on hold until the problem with --process:Separate can be resolved. (2 PRs)
3. Make resolving the --process:Separate part of this PR. (1 PR)

As anyone who knows me would guess, I prefer the 3 PR approach. I'd make them all steps in the same issue, however, since the problem really only comes up when trying to add XML elements for each project. Kind of depends on how comfortable folks are with merging code without knowing what the next step will be...

[CharliePoole]

There is an alternative. The TestCentricGUI currently examines the XML returned by the engine and re-interprets it in light of the structure of nested test packages it is attempting to run. It injects XML elements so that the test hierarchy that is displayed in the GUI contains nodes for each of the projects.

The downside of the GUI doing this is twofold

• It only works for the GUI
• The nodes are fake. The engine knows nothing about them so any action that would normally invoke the engine passing one of these nodes has to be emulated in the GUI.

I'm wondering if the same code could be ported into the engine MasterTestRunner, eliminating both downsides and keeping the logic on one place, rather than distributed in each type of runner.

I'm going to create an alternate PR for this issue.

[rprouse]

I'm fine with a three PR solution, but let's wait until you experiment with your other PR. Other than that, this looks good.

[rprouse]

Are the Analyzers causing problems for you? I like the idea of dogfooding the project, but if it is getting in the way...

[CharliePoole]

Good illustration here. Dropping the analyzers got checked in by mistake. I generally drop them since I can't build in my admittedly strange environment, but avoid committing that change. It's another step to remember to take.

We dogfooded a lot at Microsoft, but it always meant using production tools. For NUnit, we test the framework using the framework under development but using a released console or adapter. We test the adapter using a released framework, etc. That way we are testing only one thing at a time. The analyzer is the only exception to that I know of. OTOH, I'd really like to know why it causes a versioning conflict in my configuration that @mikkelbu can't duplicate.

[CharliePoole]

Alternate fix was merged. Deleting this PR.