arm detection was the result of heap corruption

[smasher164]

isFMASupported "caught" SIGILLs only in one particular test environment. Relaunching QEMU stopped this behavior. This makes sense, since Go's policy is to crash when it encounters a SIGILL.
Alternatives:

1. Attempt to fix this behavior by using the runtime's sigaction, to truly set a signal handler. ARM instructions are fixed to 32-bits, so we could potentially update the pc with c.uc_mcontext.sc_pc += 4 to avoid an infinite loop. The downsides are the lack of stability/portability in using signal handlers, as well as the unlikelihood that this would get merged as part of internal/cpu's init.
2. Parse the AT_HWCAP bits exposed by the auxiliary vector. Only the runtime has access to auxv, so we can use //go:linkname hwcap runtime.hwcap for now. The upside to this is that internal/cpu also uses hwcap, so work that is done on that front could be merged into internal/cpu.
3. Parse the output of /proc/cpuinfo. Since the set of GOARCH=ARM processors with FMA support is finite, this option is pretty doable. However, it is unlikely that the standard library would read a file on init of the math package or internal/cpu.

I'm inclined to implement option 2, since it's portable among POSIX systems.

[smasher164]

I ended up working on option 2 (see CL 126315).