Replace labeled string based access partitioning with a richer type-safe one

[sim642]

As discussed in GobCon, it would be very good to replace the labeled string based access partitioning with something that is richer (allowing more sophisticated pairwise conflict checking like #518) and more type-safe.
Also we figured that the partitioning component (LSSSet) wouldn't even be necessary, but only the "lockset" component (LSSet), since partitioning is only used by region analysis and the same should be achievable by storing regions in the latter and doing conflict checking using the region information).

This is best done after #518 to reduce conflicts.

[sim642]

The possible approach from GobCon was to add another module component to Spec for the module to be used for this access information from that analysis. That module would additionally have the pairwise conflict check function.
And then to restore the part_access function in Spec to return that spec-dependent type-safe information.

I have now realized a problem with that approach. Since #519 the access analysis is a separate dynamically toggleable analysis alongside all the others that would like to actually supply the access information. But then it would somehow need to hold in its (global) domain, values of types coming from other analyses.
This would've even been a problem before that PR because all the access stuff was simply in the mutex analysis instead. Even before that, #162 moved it there from MCP. I guess it could be moved back into MCP, which should fix the problem, although it's not so clean to have access logic scattered into the already complicated MCP.

@michael-schwarz @vesalvojdani Thoughts?

[michael-schwarz]

I don't really see another way to do this in a flexible manner other than what you have described.

The alternative would be to have a record explicitly listing all of the possible information we may want to track for accesses (the global domain being a set of such things). This individual information would then be obtained via queries (specific for each analysis or returning a variant type for the different types of available information?) and assembled in the access analysis.

But that loses any flexibility and introduces a tight coupling between the access analysis and all analyses that contribute to race checking.