exhaustiveness: speedup checking 3x-5x

[feds01]

This PR brings speedups of exhaustiveness from 3x-5x by the following changes:

This PR switches the internal exhaustiveness stores to just use Vecs over the Store interface. This avoids the locking mechanism for stores which never need to be locked.

Additionally, this also switches Fields to use a ThinVec over a Vec which leads to better performance and less memory use overall.

Finally, we don't need to store the bias on an IntRange directly, only when we need to convert back into normal values, so remove it from the IntRange struct.

In addition to performance improvements, the analysis phase now records the time taken for exhaustiveness to complete its operations, and reports them through the standard compiler metrics plumbing.

[kontheocharis]

What is ever the point of using Vec when ThinVec exists..?

[feds01]

What is ever the point of using Vec when ThinVec exists..?

I'm not too sure, it's superior for memory use, but could it potentially have performance implications?

[kontheocharis]

I guess the disadvantage is that a zero-sized Vec does not require heap allocation where as a zero-sized ThinVec does. It seems the only disadvantage is ThinVec<T> can’t ever be zero-cost roundtripped to a Box<[T]>, String, or *mut T