[BUG] Canonicalize noncanonical BOOL8 values in murmurhash3_x86_32

**Describe the bug**

Follow-up from NVIDIA/cudf#23265 and review discussion https://github.com/NVIDIA/cudf/pull/23265#discussion_r3868829030.

cuDF documents `BOOL8` as `0 == false, else true`, but `cudf::hashing::murmurhash3_x86_32` can hash noncanonical stored bytes such as 2 or 255 as their raw values instead of canonicalizing them to 1. Logically equivalent true values can therefore produce different hashes.

**Steps/Code to reproduce bug**

1. Construct a `BOOL8` column directly from raw bytes containing `{0, 1, 2, 255}`. A raw column is required because `cudf::test::fixed_width_column_wrapper` canonicalizes values during construction.
2. Hash the column with `cudf::hashing::murmurhash3_x86_32`.
3. Compare the results for stored bytes 1, 2, and 255.

The existing boolean specialization converts the stored value directly to `uint32_t`, allowing noncanonical representations to remain distinct.

**Expected behavior**

Every nonzero `BOOL8` value represents true and should be canonicalized to 1 before hashing. Stored bytes 1, 2, and 255 should produce identical hashes for the same seed.

Add explicit canonicalization (`key ? 1 : 0`) and regression coverage constructed from raw `BOOL8` bytes.

Start at cudf::hashing::murmurhash3_x86_32 and its existing boolean specialization. Reproduce the issue with a raw BOOL8 column containing 0, 1, 2, and 255, then add regression coverage showing that all nonzero values hash identically for the same seed. Done means the boolean values are canonicalized before hashing and the regression passes.

Written by the indexing model from the issue text.