Update authoring support for project references

[j0shuams]

Today, if C++ developers want to use a C#/WinRT authored component, they need to add a project reference as well as a manual reference to the component's winmd. This PR makes it so that they only need the project reference.

To accomplish this, we have changed the model for our project outputs a bit.
C#/WinRT authored components are C# class libraries that set a property so that a .winmd is made from the library's public types.
This .winmd is essential to C++ consumers, as they need to use C++/WinRT to generate a projection from the .winmd.
C# consumers need the managed implementation -- the .dll of the same assembly as the .winmd.
We tried outputting both the .dll and the .winmd but this caused issues for consumers -- mainly because they have the same assembly identity, the build system would lose track of one or the other.

This PR gives an updated model of how the project system works for authored components.
Components now only "output" their .winmd. Output here refers to the value seen by the target GetTargetPath, which is used by MSBuild to transfer project reference binaries. This provides the desired experience for C++ developers.

I have added another target that sets the component's .dll in an item group that ensures it is distributed to consumers as well. If they only got the .winmd, their app would fail. So we mark the .winmd with a new metadata value -- ManagedImplementation -- which holds the path to the implementation .dll.
In turn, the DotNet SDK needs to use this value to make sure the implementation .dll is provided at compile time. I have a PR on the DotNet SDK to do this work, and this PR should not be merged until the DotNet SDK has been updated.

If it is confusing, maybe it will help to think about how C++ users need the .dll at runtime, whereas C# users need it at compile time, which is why we need the DotNet SDK's help.

dotnet\sdk PR: dotnet/sdk#19218 (net5); dotnet/sdk#20153 (net6)

This PR fixes #808 , fixes #816 and fixes a piece of #663 related to hacking the appxmanifest.
816 is fixed because there is no more confusion on assemblies because of their identity; packaging projects "only see" the .winmd.

I have tested this using a basic component consumed by a managed app and a native app. Also tested was packaging scenarios, where a packaging project is added on top of the managed and native apps. I have tested both the project reference method of consumption, as well as the nuget package reference method.

[manodasanW]

What are the implications with the ordering of when both changes go out? If someone has this, but not the .NET SDK change what happens? If someone has the .NET SDK change, but not this, what happens?

[j0shuams]

What are the implications with the ordering of when both changes go out? If someone has this, but not the .NET SDK change what happens? If someone has the .NET SDK change, but not this, what happens?

These changes rely on the dotnet/sdk changes; if we merged these without a dotnet/sdk update, then we would break the C# customer experience. This is because we would not be threading the managed implementation through.

The dotnet/sdk changes can go in anytime, they won't break anything. The reason being that those changes only operate on the ManagedImplementation metadata item, which won't exist until we merge this. I tested it out, and checking for a metadata item that doesn't exist is safe, so dotnet/sdk can safely merge before this.

[manodasanW]

Thanks Joshua, I guess we don't merge this PR until the .NET SDK build gets publicly released with the associated change.