Redesign implicit import implementation

[rainersigwald]

As implemented (in the parser), implicit XML elements have caused a fair amount of surprise and bug tail (#1416, #1431, #1445) related to having differences between the ProjectElement tree exposed through the construction APIs and the Xml tree. We should redesign to avoid this.

I spoke to @jeffkl about this and he thought moving the transformation to be just before evaluation/preprocessing begins would be cleaner: Construction API consumers would see only the project file as it exists on disk, but the evaluator would get the complete tree as it expects. That sounds like a good plan to me.

We could also potentially go with @dsplaisted's preferred approach of implementing implicits entirely in the evaluator, but my first attempts to do so were stymied by assumptions about how the evaluation tree and the XML tree were intertwined.

[jeffkl]

@AndyGerlicher had two questions:

1. What the implications to CPS
2. Would properties be evaluated correctly from the implicit imports?

The property evaluation was something I didn't consider, if you load the project and ask for a property value that comes from the implicit import, you would expect to get it. Could the implicit imports only be evaluated in PerformDepthFirstPass?

[jeffkl]

Here's my prototype: https://github.com/Microsoft/msbuild/compare/xplat...jeffkl:implicitImports?expand=1