compileopts: add noasm default build tag

[jakebailey]

I don't know if this is a good idea or not, but, this affects github.com/zeebo/xxh3 and github.com/klauspost/cpuid/v2 which both fail to compile with tinygo unless their asm is disabled (at least for amd64 where I was testing). I am not 100% familiar with what asm tinygo supports, but my impression was that it handles none, hence setting purego? Unclear why these packages don't just use purego.

(Happy to just not do this and keep the build tag to myself if that is more acceptable, I'm just splitting apart a chain of commits in the process of getting tsgo working).

Updates #4894

[deadprogram]

This is probably a question for @dgryski or @aykevl to answer?

[aykevl]

See: golang/go#23172

The annoying thing is that "purego" means both "no unsafe allowed" and "no assembly allowed". TinyGo supports most types of unsafe code, but does not support Go assembly.
See: https://pkg.go.dev/cmd/go#hdr-Build_constraints

By convention, packages with assembly implementations may provide a go-only version under the "purego" build constraint. This does not limit the use of cgo (use the "cgo" build constraint) or unsafe.

I'm not opposed to setting the noasm build flag, but would suggest first creating a PR to those repositories to also skip assembly if the purego build tag is set.

I am not 100% familiar with what asm tinygo supports, but my impression was that it handles none, hence setting purego?

Correct. I've tried implementing Go assembly, it is theoretically possible but a massive pain due to the ABI mismatch and custom object file format.

[jakebailey]

I looked, but it's a bit awkward becuase the library in question (cpuid) just returns zeros if you disable assembly. It's a little weird for purego to mean "it doesn't work at all" given people can set purego for unrelated reasons and not mean to disable syscalls. But, I don't know how one can do any better here.