GeezerVison

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#running-unit-tests-application.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

What is the current behavior?

On Windows, getLocationInWindow(), getLocationOnScreen() and getLocationRelativeTo() fall through to ViewCommon and return undefined.

What is the new behavior?

The Windows View implements all three, in DIPs as on Android and iOS:

• getLocationInWindow(): the element's origin through TransformToVisual(null).
• getLocationRelativeTo(other): the origin through TransformToVisual(other). It returns undefined unless both views share a XamlRoot.
• getLocationOnScreen(): the in-window location plus the window's client-area origin. A new getClientOriginOnScreen(xamlRoot) util in window-helper.windows.ts reads that origin from the AppWindow (outer position plus frame insets, divided by the window scale) and caches each root's AppWindow.

Each call makes one or two native calls, and the origin point is created once.

Stacked on #11468 (base fix/windows-parent-percent-sizing).

Testing:

• Tested on Windows x64 with nativescript-mason's WebSpec suite. It measures every fixture with getActualSize() and getLocationRelativeTo(): 416/416 pass without the suite's own Windows workarounds.
• At 125% scale, getLocationOnScreen() for the window content matched Win32 ClientToScreen (109.6 × 132.8 DIPs).
• tsc -p packages/core/tsconfig.lib.json reports no errors.
• There are no specs for the Windows view.