Proposal: remove presumably unused purego support

[stapelberg]

Support for the purego build tag was originally introduced to make Go Protobuf
work on Google AppEngine (see also https://go.dev/issue/23172).

We propose to remove the presumably unused purego support to simplify the code base.

If anyone still relies on Go Protobuf’s purego support,
please let us know and explain where / how you use it.

What can we remove?

We can delete 4 alternative implementations that are build tag guarded with the
purego build tag: /~https://github.com/search?q=repo%3Aprotocolbuffers%2Fprotobuf-go%20%22build%20purego%22&type=code

We can remove the Exporter field in the internal/impl.MessageInfo type and the
related exporter functions in the generated .pb.go files.

For large Go programs, we observed up to 10 MiB of binary file size savings.

Who used the purego build tag?

Nowadays, AppEngine works differently and no longer needs the purego build tag.

Environments like WASM do not need the purego build tag either (tested with
wazero on Go 1.21.4).

This leaves GopherJS as the only remaining environment we know of that might
need the purego build tag. I spoke to @dmitshur (who used to be a maintainer of
GopherJS) and emailed with @nevkontakte (who is a current maintainer of GopherJS).

As far as we can tell, there isn’t a single notable (published) GopherJS application
that uses Go Protobuf.

There are some contributing factors: Go Protobuf is relatively heavyweight in
size, but when working with JavaScript, smaller code size translates into faster
loading times. Hence, users are more likely to reach for builtin solutions like
encoding/json.