Respect projects that say they only have one TFM

[rainersigwald]

Partially fixes dotnet/sdk#739.

The first iteration of cross-targeting support code unconditionally
queried each ProjectReference for the best TFM to build against, and
then explicitly specified that TFM when building the reference. This
caused a race condition when building a set of projects that had a
single-TFM project and another project that had a reference to it. The
entry point (probably .sln) build would build the referenced project
with no TF specified, and then the referencing project would build it
with an explicit TF specified. These two builds appeared different to
the MSBuild engine (because they had different sets of global
properties) and so were both executed, resulting in a race condition.

The fix is in two parts:

• Allow a project to report back through GetTargetFrameworkProperties
  that it only has one TF to build. (Report that a project only has one TFM sdk#797)
• When a project reports that it has only one TF to build, issue its
  build request without specifying any TF.

This commit is the latter.

[cdmihai]

Why not make ProjectHasSingleTargetFramework a separate output property of the MSBuild task rather than embedding it inside another property?

[rainersigwald]

That kind of thing (returning a tuple) would have been ideal, but I don't see a way to do it. The MSBuild task only has one output parameter, and it can be assigned either to an Item or a Property.

Returning an item has the advantage of being structured data, but it runs somewhat afoul of the current nature of assigning these properties. I put that together at dotnet/sdk#797 (comment) -- do you like that better? It's better in some ways (this "undefined, or unconditionally undefined" is definitely ugly), but worse in others (clearing the item so we can look at it one at a time, extracting the metadata for insertion into the referring project's metadata). I think on balance I like this better but I could be persuaded . . .