x/build: add a windows/arm builder using a windows/arm64 host

[qmuntal]

@zx2c4 windows/arm builder has been missing for a long time, although it still appears on the build dashboard.

I've been able to compile a windows/arm Go toolchain and run go tool dist test using a Windows ARM64 host by setting GOHOSTARCH=arm and GOARCH=arm. I believe that we could follow the same approach with the host-windows11-arm64-azure host (recently added as part of #53541), using it to run a windows/arm builder.

@heschi @thanm

[bcmills]

(CC @golang/windows)

[heschi]

GCP's ARM64 hosts can't run ARM binaries in our experience -- are you confident that Azure's can?

I think this mostly comes down to a question of resources and spending. We don't currently have enough budget to run more builders. We've gone a long, long time without windows-arm, so it's not easy for me to see a need. Can someone explain the benefit?

[qmuntal]

GCP's ARM64 hosts can't run ARM binaries in our experience -- are you confident that Azure's can?

Haven't really tried that on Azure, but I have a Windows ARM64 dev box that is surprisingly happy to run ARM binaries.

I think this mostly comes down to a question of resources and spending. We don't currently have enough budget to run more builders. We've gone a long, long time without windows-arm, so it's not easy for me to see a need. Can someone explain the benefit?

I'm not particularly interested on the windows/arm port. My main motivation to submit this idea is to have a safety net when touching the Go runtime internals for Windows that affects all its supported architectures. Having said this, if you are running short on resources I would rather have them expended on windows/arm64. I can still test that I don't break anything crosscompiling from my arm64 dev box.

[bcmills]

We've gone a long, long time without windows-arm, so it's not easy for me to see a need. Can someone explain the benefit?

I don't have an opinion of the benefit of maintaining the windows/arm port, but I do want to point out an inconsistency: given that our porting policy requires each port to have a running builder, and that we currently do not have one for windows/arm, if we decline to add a builder we should add it to the list of broken ports.