Faster f64 equality

[tustvold]

Which issue does this PR close?

Closes #.

Rationale for this change

LLVM isn't smart enough to work out that this is just a bitwise equality, so give it a hand - https://rust.godbolt.org/z/347nWGxoW

What changes are included in this PR?

Are there any user-facing changes?

[viirya]

I verified that this works for f64::NAN too.

[Dandandan]

Wouldn't the same apply for is_ne?

[ursabot]

Benchmark runs are scheduled for baseline = 8d75101 and contender = 6b3a0a2. 6b3a0a2 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on ec2-t3-xlarge-us-east-2] ec2-t3-xlarge-us-east-2
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on test-mac-arm] test-mac-arm
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on ursa-i9-9960x] ursa-i9-9960x
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on ursa-thinkcentre-m75q] ursa-thinkcentre-m75q
Buildkite builds:
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

[mbrobbel]

Is this correct? I don't think this is valid for NaN: https://github.com/rust-lang/rust/blob/a3c0a023611fcaf5ae3ec242d7d60e356041d25f/library/core/src/num/f64.rs#L426.

[tustvold]

@mbrobbel This crate follows the totalOrder predicate as defined in the IEEE 754 (2008 revision) floating point standard, which is different from the default PartialOrd and PartialEq implementations provided by Rust for floating point numbers. Instead using https://doc.rust-lang.org/std/primitive.f32.html#method.total_cmp