Make sure to use the correct p/invoke for 32-bit

[mattleibow]

Description of Change

Windows uses 2 entirely different methods to set things like WndProcs: SetWindowLong on x86 and SetWindowLongPtr on x64.

Added a x86 Platform to the sample app so we can test this arch.

Additions made

• Use the correct SetWindowLong vs SetWindowLongPtr depending on the arch
• Added a helper GetWindowHandle extension method to platform Window

PR Checklist

• Targets the correct branch
• Tests are passing (or failures are unrelated)
• Targets a single property for a single control (or intertwined few properties)
• Adds the property to the appropriate interface
• Avoids any changes not essential to the handler property
• Adds the mapping to the PropertyMapper in the handler
• Adds the mapping method to the WinUI, Android, iOS, and Standard aspects of the handler
• Implements the actual property updates (usually in extension methods in the Platform section of Core)
• Tags ported renderer methods with [PortHandler]
• Adds an example of the property to the sample project (MainPage)
• Adds the property to the stub class
• Implements basic property tests in DeviceTests

Does this PR touch anything that might affect accessibility?

• Does this PR introduce a new control? (If yes, add an example using SemanticProperties to the SemanticsPage)
• APIs that modify focusability?
• APIs that modify any text property on a control?
• Does this PR modify view nesting or view arrangement in anyway?
• Is there the smallest possibility that your PR will change accessibility?
• I'm not sure, please help me

If any of the above checkboxes apply to your PR, then the PR will need to provide testing to demonstrate that accessibility still works.

[marb2000]

You can use the new WinRT Interop helpers and remove the IWindowNative definition:

 IntPtr hwnd = WinRT.Interop.WindowNative.GetWindowHandle(m_window);

[mattleibow]

Thanks! Updated to use that and deleted a file from our code.