runtime: fix sigtramp on windows arm64 platform

Fixes: golang#43800

This fixes the sigtramp handler on Windows.  Note that unlike linuxy
platforms, sigtramp is not actually a "trampoline" function.  Instead,
The code needed to handle interrupts in userspace is provided by
Windows by some other means.  On Windows the mechanism they provide is
called "Vectored Exception Handling".  Windows provides the
AddVectoredExceptionHandler to register a callback function whenever an
interrupt occurs which could be triggered by a signal/exception/etc.
Windows supports multiple handlers and will call them one after the other
stopping or continuing based on the return value as it goes along.

In the case of go, it appears that sigtramp doesn't need to handle
exceptions on threads that it hasn't initialized with the runtime.  So
in the case of windows, returning 0 from the exception handler will
cause it to move on to the next exception handler.  This is the change
I've made here.

This change has been built and verified to fix golang#43800 on a hololens
arm64 windows device.

Note that this also appears to be a problem for arm (sys_windows_arm.s).
I'm currently not set up to test this on arm so maybe this could be
fixed in a follow up change.

src/runtime/sys_windows_arm64.s

@@ -170,9 +170,16 @@ TEXT sigtramp<>(SB),NOSPLIT|NOFRAME,$0
 
 	BL      runtime·load_g(SB)	// smashes R0, R27, R28 (g)
 	CMP	$0, g			// is there a current g?
-	BNE	2(PC)
-	BL	runtime·badsignal2(SB)
+	BNE	g_not_nil
 
+	// in this case this is not a go thread, just return that we don't handle the exception
+	MOVD	R7, LR
+	MOVD	R16, R27		// restore R27
+	MOVD	R17, g 			// restore R28
+	MOVD	$0, R0			// return 0 (EXCEPTION_CONTINUE_SEARCH)
+	RET
+
+g_not_nil:
 	// Do we need to switch to the g0 stack?
 	MOVD	g, R3			// R3 = oldg (for sigtramp_g0)
 	MOVD	g_m(g), R2		// R2 = m