hlo_reachability: make operator|= friendly to auto-vectorization
hlo_reachability: make operator|= friendly to auto-vectorization

This vectorizes the OR loop, at least with clang trunk on
AVX-capable x86 CPUs.

name                                  old time/op  new time/op  delta
BM_HloReachabilityBitSetUnion/1       1.50ns ± 0%  2.99ns ± 0%  +99.47%  (p=0.008 n=5+5)
BM_HloReachabilityBitSetUnion/64      1.50ns ± 1%  2.99ns ± 0%  +99.51%  (p=0.008 n=5+5)
BM_HloReachabilityBitSetUnion/128     2.62ns ± 0%  3.74ns ± 0%  +42.96%  (p=0.008 n=5+5)
BM_HloReachabilityBitSetUnion/256     4.86ns ± 0%  5.23ns ± 0%   +7.54%  (p=0.008 n=5+5)
BM_HloReachabilityBitSetUnion/512     9.35ns ± 0%  4.31ns ± 9%  -53.92%  (p=0.008 n=5+5)
BM_HloReachabilityBitSetUnion/4096    72.2ns ± 0%  19.8ns ± 0%  -72.52%  (p=0.008 n=5+5)
BM_HloReachabilityBitSetUnion/32768    589ns ± 0%   152ns ± 0%  -74.22%  (p=0.016 n=4+5)
BM_HloReachabilityBitSetUnion/262144  4.71µs ± 1%  1.84µs ± 0%  -61.01%  (p=0.016 n=4+5)
BM_HloReachabilityBuild/1              165ns ± 1%   164ns ± 0%     ~     (p=0.343 n=4+4)
BM_HloReachabilityBuild/64            6.28µs ± 3%  6.37µs ± 4%     ~     (p=0.548 n=5+5)
BM_HloReachabilityBuild/128           13.1µs ± 5%  13.0µs ± 1%     ~     (p=0.690 n=5+5)
BM_HloReachabilityBuild/256           28.4µs ± 4%  27.6µs ± 2%   -2.65%  (p=0.032 n=5+5)
BM_HloReachabilityBuild/512           62.1µs ± 2%  59.8µs ± 1%   -3.68%  (p=0.008 n=5+5)
BM_HloReachabilityBuild/4096          1.17ms ± 1%  0.98ms ± 2%  -16.49%  (p=0.008 n=5+5)
BM_HloReachabilityBuild/32768         52.4ms ± 1%  41.7ms ± 2%  -20.45%  (p=0.008 n=5+5)
BM_HloReachabilityBuild/262144         4.77s ± 7%   4.23s ± 6%  -11.43%  (p=0.008 n=5+5)

Some notes:
- For small inputs (e.g. n <= 64), vectorization is overkill for the "Union"
  benchmark and therefore slower than the scalar baseline. However, this
  slowdown is not measurable in the "Build" benchmark, which is where BitSet's
  "or" (a.k.a. "Union") op is used.
- The benefits of vectorization might fizzle out given large enough inputs--see
  the reduced speedup from 32K to 256K inputs--, which is probably due to the
  reduced cache locality.

Assembly snippets (via `perf annotate`):
             0000000034fa1640 <xla::(anonymous namespace)::BM_HloReachabilityBitSetUnion(benchmark::State&)>:
             xla::(anonymous namespace)::BM_HloReachabilityBitSetUnion(benchmark::State&):
- Before:
        138:   xor    %esi,%esi
  0.00         nop
 12.61  140:   mov    -0x30(%rbp),%rdx
  2.61         mov    (%rdx,%rsi,8),%rdx
 13.57         or     %rdx,(%rax,%rsi,8)
  2.17         inc    %rsi
  0.15         mov    -0x50(%rbp),%rax
  0.05         mov    -0x48(%rbp),%rdx
 12.38         mov    %rdx,%rdi
  2.40         sub    %rax,%rdi
  0.03         sar    $0x3,%rdi
  0.02         cmp    %rdi,%rsi
  0.10       ↑ jb     140
  3.59       ↑ jmp    e3

- After:
  0.04         xor     %r8d,%r8d
  0.51         cs      nopw 0x0(%rax,%rax,1)
  2.27  180:   vmovups (%rdx,%r8,8),%xmm0
  1.84         vmovups 0x10(%rdx,%r8,8),%xmm1
  1.39         vmovups 0x20(%rdx,%r8,8),%xmm2
  1.18         vmovups 0x30(%rdx,%r8,8),%xmm3
  8.69         vorps   (%rax,%r8,8),%xmm0,%xmm0
  4.81         vorps   0x10(%rax,%r8,8),%xmm1,%xmm1
  6.02         vorps   0x20(%rax,%r8,8),%xmm2,%xmm2
  4.38         vorps   0x30(%rax,%r8,8),%xmm3,%xmm3
  2.57         vmovups %xmm0,(%rax,%r8,8)
  0.89         vmovups %xmm1,0x10(%rax,%r8,8)
  2.39         vmovups %xmm2,0x20(%rax,%r8,8)
  1.10         vmovups %xmm3,0x30(%rax,%r8,8)
  1.70         add     $0x8,%r8
  0.30         cmp     %r8,%rdi
  0.40       ↑ jne     180
               cmp     %rdi,%rsi
  0.62       ↑ je      90
             ↑ jmp     d7

FUTURE_COPYBARA_INTEGRATE_REVIEW=https://github.com/openxla/xla/pull/9319 from jaro-sevcik:no-cublas-or-triton-for-small-matmuls 690bb0e1d8b5894f64134d68a031d387399c638f
