Edited Issue: Better management of native transitive dependencies [3160]

Consider a native solution:
1. A native Win32 console application, named A.
2. A native Win32 static library, named B.
3. The console app A has a project dependency on B, and calls B's code.
2. A native Win32 static library, named C.
3. The console app B has a project dependency on C, and calls C's code. No C types are exposed through B's public header files.

This works fine. Now:
1. Remove project C.
2. Change project B to have a NuGet dependency on native package C2.

Now, get a build failure:
```
1>------ Build started: Project: ConsoleApplication12, Configuration: Debug Win32 ------
1> All packages listed in packages.config are already installed.
1> test1.cpp
1> ConsoleApplication12.vcxproj -> c:\users\jcooke\documents\visual studio 2012\Projects\ConsoleApplication12\Debug\ConsoleApplication12.lib
2>------ Build started: Project: ConsoleApplication1, Configuration: Debug Win32 ------
2>ConsoleApplication12.lib(test1.obj) : error LNK2019: unresolved external symbol "public: static double __cdecl C2::Add(double,double)" (?Add@C2@@SANNN@Z) referenced in function "public: static int __cdecl test1::doit(void)" (?doit@test1@@SAHXZ)
2>c:\users\jcooke\documents\visual studio 2012\Projects\ConsoleApplication12\Debug\ConsoleApplication1.exe : fatal error LNK1120: 1 unresolved externals
========== Build: 1 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========
```

One fix is to update project A to have a NuGet reference to C2, but that seems wrong, given that is unnecessary for the vanilla native solution, and it is also unnecessary for a managed project with a similar structure.