Don't use direct field access in Simd functions

[Sp00ph]

See https://rust-lang.zulipchat.com/#narrow/stream/257879-project-portable-simd/topic/splat.20no.20longer.20compiles.20for.20release.20builds/near/351949106

[workingjubilee]

Please document why we have to do it this way, so no one tries to be "helpful" and open a PR "fixing" this.

[Sp00ph]

Where do you think would be the best place to put such a disclaimer? Should I just put it on the Simd struct directly, since it's not specific to the changed functions? Or maybe both on the struct and on the changed functions?

[workingjubilee]

Let's do this belt-and-suspenders style, yeah. Double up. It can be terse but it should be in both places.

[Sp00ph]

I expanded the comment a bit to also include that you can't directly construct the type either, as I don't think it's obvious that that counts as a field access (and also had a typo in the previous commit message).

[calebzulawski]

I think you can remove the transmute feature now

[Sp00ph]

This is the second time in a row now that the x86_64-apple-darwin test failed because it wasn't able to reach https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256. Looks like something's wrong with that machine.

[jhorstmann]

Sounds like this could already be the fix to what I just reported in rust-lang/rust#110722