This was supposed to trick compilers to avoid leaking secret (one-time)
key material to stack in poly1305(). The trick indeed worked on few test
compilers, but unfortunately generated utter shit with other compilers.
However, I refactored and rearranged the poly1305 code a bit in order to
make it harder for compiler(s) to generate code that leaks poly1305 otk
material via stack memory. Register spilling still happens though, so
there is not much we can do fully protect poly1305 one-time keys from
stack memory disclosure attacks etc.

Nonetheless, this is a minor issue and all C crypto libraries suffer
from the same issue. Fortunately, poly1305 keys are one-time only so the
impact is low even if the attacker somehow manages to get access to the
keys. Basically a compromised poly1305 one-time key would allow message
forgery, but not decryption. Switching from random poly1305 one-time
keys to deterministic (hash-based) one-time keys would prevent forgery
attacks as well.