Add privatization of effectively thread-local globals

[sim642]

This is currently on top of #1965.

Inspired by the analysis of signal handlers as threads, it occurred to me that it is very imprecise to make the analysis go into multi-threaded mode if even one signal handler is installed, because the analysis of all globals becomes flow-insensitive.
At least with signal handlers, they are (supposed to be) small and usually read/write very few global variables. So if the rest of the program is single-threaded, it's quite crude to analyze all globals flow-insensitively.

It would be much more precise to only analyze those globals flow-insensitively which are read/written by a signal handler. All other global variables could be analyzed flow-sensitively still.
In fact, this could also be done in actual multi-threaded programs for globals which are effectively thread-local, i.e. only used by one thread.

It's kind of difficult to achieve this right now (to apply privatizations selectively) but this is a dirty attempt. The threadAccess analysis computes for each global the set of threads accessing it. If it's a singleton, then it answers the MayBePublic query negatively, which should improve precision of some protection-based privatizations.

Some privatizations with TIDs might be able to do this out of the box anyway (?), but this kind of thing should be possible also for others, thus some extra analysis.
It isn't currently as generic as it could be though: with none privatization (as used by large-program conf), the query isn't used and this cannot help, although the same selective flow-(in)sensitivity should still be possible.

TODO

• Probably should also require the thread to be unique, which Make signal handler threads unique #1965 would give for signals.
• Consider effectively thread-local variable becoming truly global. Probably broken right now and might require escaping-like support.