wpf: delay-load UIAutomationCore because it's incomplete in RS1

[DHowett]

UiaRaiseNotificationEvent is not present on Windows Server 2016, even though it is documented as being present.
This also removes the cost of loading up UIAutomationCore from the critical path.

[DHowett]

Note it no longer shows up in the import list!

$ depends -windir:v:\wim\windows E:\src\Terminal\bin\x64\Debug\PublicTerminalCore.dll

=== e:\src\terminal\bin\x64\debug\publicterminalcore.dll ===

  Dependencies:
    advapi32.dll
    api-ms-win-core-synch-l1-2-0
    bcrypt.dll
    d2d1.dll
    d3d11.dll
    d3dcompiler_47.dll
    dwrite.dll
    dxgi.dll
    kernel32.dll
    ole32.dll
    oleaut32.dll
    ucrtbased.dll
    user32.dll

27 modules loaded, 8563 functions resolved

[PankajBhojwani]

We're checking _notificationsUnavailable here but the first time we actually (might) set it is in _tryNotify which is called later in this function. That means the first time we enter this function we are always doing the same thing as before, and only on future calls do we potentially skip attempting to notify. Is it possible for us to set the proper value for _notificationsUnavailable for the first call as well?

[DHowett]

In this case, we are "late-binding" the failure state. We want to act as though everything works on all platforms, and only when it fails (on Windows 8.1 or RS1) update the state to avoid wasting any future effort on new notification generation.

One of the core principles of delay loading is that you get failures at the time of use (in the default config). Checking beforehand is a bit of a waste of time in that case... and the cost of one miss when accessibility is enabled on a very rarely-used platform is not high enough to make me want to do any preflight checking :)

[DHowett]

Effectively, this is "try to notify, stop ever trying again if it fails", which means we don't complicate any other codepaths.

There are other places where we could "pre"check, and none of them sound great to me. Here's where--and why.

• We could check when a HwndTerminalAutomationPeer is constructed
  • This might happen on startup, which moves the loading of UIAutomationCore back onto the startup path
• We could check at the top of this function
  • Doing this only once requires a magic static, which requires a thread local storage slot and a lock to ensure exclusivity

/DELAYLOAD operating as normal is cheaper than both of those 😄

We could also just not store the failure state and let the delayload failure trip every time. It's not THAT expensive... but it could fire once per keyboard input (!) or any text output (!) in the worst case.