stb_ds hmput breaks if side-effect on key

[nothings]

This can't be reproduced on MSVC because it must be an lvalue so it can't compile. But on gcc/clang we have a workaround that allows rvalues. Somebody half-reported this by email, ambiguous whether it actually happens or just was worried it happens.

When the core hmput runs, the shput path assigns the key to a temp value, and the main path uses a memcpy to copy the key into place. After the core runs, the macro stores the key into the table again, but this time with an assignment (since in the macro the types are exposed). This is where the key is evaluted twice.

Is that assignment even needed? It's "better" for C++ in that it allows assignment constructor to run, but I'm not sure the rest of hmput would even work in cases where the assignment constructor is needed. Maybe there are fallback paths where it's necessary because the memcpy isn't run? But otherwise, the memcpy should be enough so it might be worth checking just removing the line.

If not, need to document that the key shouldn't have side-effects.