Understand impact of cpu-architecture specific floating-point optimizations on join plans.

[nicktobey]

There are a small number of join plans that, as of the current main branch (2f7e3c8), produce different plans on AMD vs ARM processors.

These are the ImdbQueryPlan tests. The affected tests in this test suite are currently disabled.

As best as I currently understand it, here is why this is happening:

1. There are multiple possible join plans for these queries that have theoretically identical costs
2. Due to floating-point errors, one of these plans will actually have a slightly lower cost than the other (by a single epsilon), resulting in it being preferred over the other.
3. The Go compiler is allowed to emit instructions that produce less floating point error than would be implied by a strict implementation of IEE-754. (See spec: allow the use of fused multiply-add floating point instructions golang/go#17895 for more context)
4. The exact behavior of these instructions is CPU dependent

As a result, it becomes possible for Dolt running on ARM processors to pick one plan, and Dolt running on AMD processors to pick another.

In practice, this likely doesn't matter much: if two joins literally have the exact same cost estimate, it's extremely likely the plans are effectively identical, ultimately represent the same physical operation, and have the same performance characteristics in practice.

But it matters for tests, and we should consider how to address this.