Deprecate and hide from Intellisense APIs that always return null, like Window.Current

[andrewleader]

Describe the bug

There are several APIs in our API surface that always return null and confuse developers, like Window.Current and also Window.Dispatcher and more. The presence of these non-functional APIs makes it more difficult to code and more difficult to migrate from UWP, since any developer would expect these APIs to work since they're there, but they actually just return null.

These APIs only worked in UWP, which was why we had them, but we need to clean up the API surface.

Expected behavior
These APIs should be removed, or at least marked deprecated. Since we're not going to be able to remove these before 1.0 GA and removing would be a breaking change, we're planning on marking them deprecated and hiding them from intellisense in 1.0 servicing or 1.1, and then removing in 2.0 with #1776.

[mqudsi]

Can you hide them from intellisense (before then) by annotating the declarations?

[riverar]

Prior art:
microsoft/microsoft-ui-xaml#2609
microsoft/microsoft-ui-xaml#4177
microsoft/microsoft-ui-xaml#6027

[andrewleader]

Hiding from intellisense is a good idea @mqudsi, I've added that! We still won't be able to do anything any sooner though, we simply don't have the time to annotate the APIs right now before 1.0 GA. But hopefully we can annotate the APIs soon after 1.0 GA.

[dotMorten]

Perhaps a code analyzer that will error? I realize you can't remove these APIs because that is breaking binary compat, but the APIs are already "broken". One of the largest porting issues coming from UWP is all your code compiles and runs just fine until that specific line of code is called - which you might not actually hit during testing until a customer does. I don't want my app to compile at all if I'm using these broken APIs.