refactor: noasm to purego

[leongross]

Is there a good reason to use the noasm tag in this project contrary to adapting the build tag purego? As I see it, they both mean the same thing or am I confusing concepts here?
The Golang Standard Library utilizes this build tags for e.g. generic cryptography implementations.
It might be a good idea to adjust this project's build tags to the widely adopted scheme.

[klauspost]

First of all we can't change it. Second, as you point out it is pointless to have both.

[leongross]

What do you mean we can't change it? Why can't the noasm tag be adjusted to purego? What is the blocker? I see that other projects that include compress as a dependency need to adjust this, but adjusting to purego and reducing the set of build tags developers have to take care of while providing the same functionality sounds like a good idea.

[klauspost]

Because people are using it.

[leongross]

as you point out it is pointless to have both

I don't think it is useless. Aliasing purego to noasm (go:build (noasm || purego)...) guarantees backward compatibility and also adapts to newer conventions. I only see benefits for developers, since they do not have to look up how library x enables pure go support but can just go the default way with the purego tag.