crypto: use purego tag consistently

[FiloSottile]

We've been inconsistent in using the purego tag in the standard library because it was not clear what would be its use aside from letting me benchmark assembly vs native code. I noticed on the Gophers Slack that tagging purego consistently would probably make TinyGo's life easier when trying to compile crypto packages, and presumably any other Go compiler. https://tinygo.org/docs/reference/lang-support/stdlib/#crypto

It's easy enough to do, so why not. Might also add a purego compilation test of crypto/... to longtest.

/cc @dgryski

[dgryski]

The hash/crc32 package also needs purego tags.

[cuonglm]

FYI, the purego proposal is accepted #23172

I also had https://go-review.googlesource.com/c/go/+/468795, which implements a purego version of hash/maphash. There, you can add the test with purego tag in cmd/dist.

[gopherbot]

Change https://go.dev/cl/561935 mentions this issue: crypto: use and test purego tag consistently

[gopherbot]

Change https://go.dev/cl/561955 mentions this issue: TargetSpecific: update purego tag guidance

[aykevl]

To be clear, purego means "use Go instead of assembly"?
I'm asking, because it could also be interpreted as "don't use CGo". In TinyGo we do support CGo (with some limitations) but Go assembly is very difficult due to the special syntax and different calling convention. So basically we'd like to set the purego tag by default to avoid assembly but would still like to use CGo.

In #23172 it seems that purego is defined as "no assembly, unsafe, or CGo", which combines a number of unrelated features and would not fit very well with TinyGo.

It's probably much too late to change, but noasm would be a much better fit for TinyGo because it's more explicit (and similarly, nounsafe could be used - for CGo we already have the cgo build tag).

Related: tinygo-org/tinygo#4116