Investigate solutions for fragility between wpf and wpf-int

Whenever the compiler changes its CIL version (would happen on some VS updates), WPF will break until wpf-int rebuilds and flows into wpf. This is annoying, but a larger problem now with the VMR, because wpf-int must flow to wpf, then wpf into the VMR, before the VMR will build again.

This happens because LTCG compilation to a .lib encodes the CIL rather than compiled machine code. When LTCG linking happens against the input lib + other source objs to create a PE, the CIL versions must match for things to work. This is **generally** not an advised way to compose a product because of the fragility of the CIL interface.

The suggestion is that LTCG should be turned **off** for native libraries in wpf-int that are packaged up into nupkgs and used downstream. We would need to understand the following:
- Why was this turned on in the first place
- What are the performance implications.

bilinearspan.lib appears to be at least one source of issues.

/cc @ViktorHofer @ericstj