There is a sign-extension bug happening when packing 2 32-bit ints into
a 64-bit int. We are OR-ing int32_t with a uint64_t, so an integral
conversion converts int32_t to uint64_t, which is a sign extension, and
this gives unexpected results for a negative value:

    0x80000000 | uint64_t{0} -> 0xffffffff80000000

What we want is 0x0000000080000000.

Created a helper function to do this work of combining two uint32_t
into one uint64_t. The use of this function will also ensure that
if callers passed a int32_t, it would first be converted to a
uint32_t, and will not have this sign extension bug.

Sneaked a small regression test into the existing v128.const cctest,
and also cleanup the loop to reset `expected` array to 0.

Bug: chromium:1104033
Change-Id: Icaca4c5ba42077dd4463697b9220cdbca9974b5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2293044
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68850}