panic in the unreachable stubs instead of forwarding to the pure code

[BobDu]

On arm64 hash_avx512.HashF forwards to hash_pure.HashF, which reads like a fallback, but consts.HasAVX512 is false there so the dispatch never reaches it. It is a placeholder that exists only so the package compiles. Working that out took me a while when I was getting familiar with the repository, and a panic would have said it outright.

The // +build lines have not been needed since Go 1.17 and the go directive here is already 1.20, so they are gone. The files now take their constraint from their names rather than a tag inside, which leaves an explicit tag only where one is needed.

[zeebo]

My reason for the fallback was that if there was some bug where the method does get called somehow (for example, we attempt to call the avx512 code on arm64), then the library still works, it's just slower than it should be. I prefer that outcome to a panic. Can we instead add a comment for future readers instead of the panic? Maybe we can use testing.Testing() and panic if that's true and fallback otherwise (I don't mind bumping to go1.21)?

[BobDu]

hash.go and compress.go import every backend on every architecture, which is what forces hash_avx2 and the others to have a file for arm64 in the first place.

If the dispatch is split per architecture instead, hash_avx2 no longer needs its impl_other.go at all, the choice between forwarding and panicking disappears with it, and whether an arm64 build can reach amd64 code becomes something the compiler decides rather than something to guard at run time.

The layout follows crypto/sha1: sha1block_amd64.go, sha1block_arm64.go and sha1block_generic.go; x/crypto's blake2b has the same shape.

@zeebo I redid this as #57; how does it look? 👀