support memset on 128bit integers

[brody2consult]

This is a quick solution to support the case I described in #594:

pub fn new_array_zero_fill_u128() -> [u128; 4] {
    return [0; 4];
}

This proposal would help me get past the first build issue I have encountered with RustCrypto.

I would love to support non-zero memset fill for both u128 & i128 as discussed in #594, but this would involve some more work in testing to hopefully ensure that this is done correctly & not likely broken by potential future refactoring.

I would be happy to address any possible feedback on my first contribution to Rust-GPU.

TODO

• squash commits before merging - Reviewers please let me know if you want me to do this or if you want to do this yourself

[brody2consult]

A couple nits - I am already testing a resolution in personal PR: brody2consult#1 - now resolved ✅

I will push the updates to this PR if I do not encounter any failures in brody2consult#1 - now done ✅

[Firestar99]

I've generalized it to work with arbitrary bitpatterns and on signed and unsigned 128 bit integers. If you could confirm this patch works for you, I'd be happy to merge it.

I wrote this into the compiletest:

crypto-common has a proc macro to implement code for u8, u16, u32, u16 and u128, which means we need our codegen
to handle the u128 case for the crate to even compile. Specifically, this calls memset_const_pattern with u128.

Note that the u128 path is unusable anyway as 128bit integer are not supported in SPIR-V. So if this is used nowhere
in any entry point, our post-link DCE will remove the u128 code and the SPIR-V will be valid.
https://github.com/RustCrypto/traits/blob/f896a76d4468f1ff855b651124fd5b5378a3417f/crypto-common/src/hazmat.rs#L61-L83

Generally, we do accept patches that do enable you to use crates that previously didn't compile, even if you can't use the u128bit path. In similar vein, we've added black_box support by just doing a noop, since we can't actually provide a proper black box in SPIR-V.