Refactor and fix race access distribution

[sim642]

This is the result of reverse-engineering the existing race access distribution code. That code is cleaned up, simplified and commented.

This does not yet do anything clever to avoid distributing accesses to many memory locations, but makes the rules for doing so a lot clearer, hopefully simplifying the redesign.
However, the number of accesses, memory locations and races may change as the result of this PR, in particular due to some included soundness fixes.

Changes

1. Define a new Access.Memo type for precisely representing memory locations as used by the race analysis.

   The previous representation used two options, of which not all four combinations were possible, and both of them could contain offsets, which were duplicated.
   The new representation has a varinfo or typ as root, followed by unit-indexed offsets. This also allows reusing features from Refactor offsets, lvals and addresses #1067.

2. Completely rewrite Access.add_propagate as add_distribute_outer.

   Its previous logic was very confusing and completely unexplained. In some ways it had an overly specific special case, while the general case was both too precise or too imprecise, depending on the situation. The new logic generalizes this to two general principles according to which type-based accesses are distributed:

   1. A type-based access is distributed to all global variables of that type.
   2. A type-based access is distributed to all struct fields of that type. This aspect is recursive, i.e. those are also distributed to global variables, etc.

   The new logic fixes both soundness and precision issues that existed previously.

3. Fix unsoundness regarding distribution to struct fields with array type.

   Previously accesses via int* didn't account for the possibility that it might point to and thus race with an element of a struct field with type int[2]. Now arbitrarily deep multi-arrays are unwrapped.

4. Rename and flip ana.mutex.disjoint_types to ana.race.direct-arithmetic.

   This should somewhat clarify the meaning of the option and avoid double negation (not !unsound). Disjoint types is rather nondescriptive since it really just controls the behavior of direct (i.e. non-field) accesses to arithmetic-type–based memory locations.

5. Moves the handling of ana.race.direct-arithmetic to just one place.

   Previously two partial checks were in two different places, obfuscating the logic.

6. Exclude accesses to some anonymous pthread type internals, which show up as __anonstruct and __anonunion.

   Existing exclusions are based on TNamed, so simply typedef names. But anonymous structs are precisely the ones that don't have such names.

7. Remove polymorphic Hashtbl usage from Access.

   Although it didn't cause issues as the hashtables were with typsig keys, it's still nicer to avoid the possibility explicitly. typsigs are still used to make sure that all type-based accesses are collected regardless of any typedefs.

8. Add access tracing.

9. Add option warn.deterministic.

   This makes the order of printed messages deterministic, by delaying the printing and later printing them in sorted (by text, etc) order. This is useful for writing cram tests such that the test doesn't spuriously break (e.g. on OSX) due to different varinfo IDs being in different order in some hashtables that get iterated.

TODO

• Remove system-dependent cram tests.

[michael-schwarz]

Why is this a polymorphic variant type?

[sim642]

This could be changed, but I don't want to do it here right now since #1089 and more follow-up already build on this, so it's best to avoid massive conflicts there.
Once all the big usability improvements to the race analysis are done, we'll see which types remain at all.

[michael-schwarz]

Definitely looks a lot more reasonable now. I am a bit unhappy with the number of TODO comments we're adding here though! I don't think we'll ever be in a better situation to address these than now.

[sim642]

I am a bit unhappy with the number of TODO comments we're adding here though! I don't think we'll ever be in a better situation to address these than now.

None of the added TODOs should be new problems, they're existing (possible) problems, so it's better to mark them than completely ignore them and I cannot fix all of them in a single PR.
#1089 and its follow up should address some of them. It doesn't make sense to try to fix them here if the whole system ends up getting thrown away and redesigned from scratch.
Others have been and are open questions that I still don't have answers to. For example Access.get_type is still a complete mystery even after days of staring at it.