Add 8x16 shift legalizations for x86 SIMD

[abrown]

• This has not been discussed in an issue.
• A short description of what this does, why it is needed: I did not implement the i8x16 shifts previously because there was discussion about whether they should be included in the spec (Inefficient x64 codegen for 8x16 shifts WebAssembly/simd#117). I still feel they should not be included due to the large overhead they impose on x86 but I am (rather unwillingly) implementing them here so we can get additional performance measurements.
• This PR contains test cases, if meaningful.
• A reviewer from the core maintainer team has been assigned for this PR.

[abrown]

@sunfishcode, @bnjbvr: I don't know how to get a pointer to the table of constants but I need something like that in order to load the mask. Is there a different way to do this? I looked at binemit.rs::const_disp4 and I don't have sink (present there) when I'm here (doing legalizations).

[abrown]

@sunfishcode, here's my current thinking on this:

• I considered whether having some sort of symbol (unrelated to globals) in the CL IR like $func.rodata would make this work; if that symbol could have a known address at compile time then I could use that and constant offsets to get at runtime-determined constants.
• But can the address of that symbol be known at compile time? I think it can if it is function-related (not global) and relative to the PC: 1) once we know how long the function will be, calculate all of the offsets of jump tables, constants, and (now) symbols, and 2) use functions like jt_disp4, const_disp4, and (now) symbol_disp4 in binemit.rs to pull out those calculated offsets when we emit the code.
• Looking at this from distance, we would be doing the same type of thing three times and the code is fragile due to the distance between when the offsets are assigned (relax_branches), referenced in code (binemit.rs), and actually populated with data (emit_function). Perhaps we add an abstraction to Function like RelativeOffsets that would map any of these things (jump table, constant, symbol) to their offset; it would only be usable after some new counting pass (removing that logic from relax_branches), would be queryable when encoding instructions and would know how to lay out the actual data in emit_function

[alexcrichton]

Thanks for the PR again, and as a procedural note the Cranelift repository has now merged into the wasmtime repository.

PRs are no longer landing in this repository, and unfortunately there's no "one button" solution to move a PR to the wasmtime repository. A script has been prepared, however, to assist you in transferring this PR to the wasmtime repo. Feel free to reach out on Zulip with any questions!