Support UI Automation within a Windows Defender Application Guard process (#7600)
* Prototype support for WDAG (Windows Defender Application Guard)
changes:
* UIAHandler.getNearestWindowHandle: If this UIAElement's processID is for a local WDAG container process, jump up to its root (UIA className of "ApplicationFrameWindow") and use that element's windowHandle. Any windowHandle from UIAElements below this root are not valid on this machine. However before we check for the WDAG process, if the processID of the original element is 0, search up for the first valid one (Known WDAG bug)
* UIAHandler.IsNativeUIAElement: If the processID is 0 (such as with UIAElements currently in WDAG), treat this UIAElement as having a native UIA implementation
* UIA NVDAObject: don't get the processID of the UIAElement, instead fallback to getting it off its window. Currently a UIAElement in WDAG may have a processID of 0. This is a known bug. It should be the processID of the local container process.
* * UIAHandler.isNativeUIAElement: if the processID is for the local wdag container process, then this element should be classed as being native.
* Ensure IUIAutomationElement.cachedNativeWindowHandle is never used when it is not local -- needs to be rethought a bit.
* UIAHandler.isUIAWindow: mark RAIL_WINDOW as always being native UIA. this allows screen hittesting, and allows us to remove some other code from UIAHandler.isNativeUIAElement.
* remove some unneeded code
* Remove more unneeded changes
* Address review actions
* UIAHandler's getNearestWindowHandle: partial support for File Explorer in WDAG by also looking for File Explorer's UIA class name.