runtime: fix badsignal2 to initialize r3 with a valid address

We ran into an issue on the hololens which is an arm64 windows platform.
We noticed that in runtime.badsignal2 it would call WriteFile, but then
we would get an Access Violation inside it when it attempted to derefence
the lpNumberOfBytesWritten variable. It appears that runtime.badsignal2
is assigning this variable, which is a pointer, to whatever is in r13
(note this is assembly), but I don't see where r13 is initialized and in
our case it was set to 1, so WriteFile ended up dereferencing the value 1
causing the Access Violation.

This change initially modified the assembly to set r3 to 0 which would
fix the issue by allowing WriteFile to print the error message and then
return, however, according to Microsoft's docs, lpNumberOfBytesWritten
should only be assigned "NULL" if the overlapped argumet is not NULL, which
is not the case here.  So I've updated the assembly code to set R3 to a
location on the stack.

Note that it's likely this issue hasn't been noticed because it occurs
right before an abort so the result ends up being almost the same except
the error message doesn't get printed to stderr. Also this would sometimes
work because whatever happens to be in r13 could be 0 or a valid pointer.

Author: marler8997

src/runtime/sys_windows_arm64.s

@@ -112,10 +112,11 @@ TEXT runtime·badsignal2(SB),NOSPLIT,$16-0
 	MOVD	$runtime·badsignalmsg(SB), R1	// lpBuffer
 	MOVD	$runtime·badsignallen(SB), R2	// lpNumberOfBytesToWrite
 	MOVD	(R2), R2
-	MOVD	R13, R3		// lpNumberOfBytesWritten
 	MOVD	$0, R4			// lpOverlapped
 	MOVD	runtime·_WriteFile(SB), R12
-	SUB	$16, RSP	// skip over saved frame pointer below RSP
+	MOVD	RSP, R3		// lpNumberOfBytesWritten, point to stack - 24 bytes (see next instruction)
+	SUB	$24, R3
+	SUB	$32, RSP	// skip over saved frame pointer, lpNumberOfBytesWritten and align to 16 bytes
 	BL	(R12)
 
 	// Does not return.