Fix translation of atomic functions

[schuessf]

PR #657 added support for atomic functions. This had however two problems (in the current version):

• To improve our performance, this PR tried to avoid unecessary heap variables, i.e., we tried to translate __atomic_store_n(&x, 1, 5) to x := 1 inside an atomic block rather than write~(x, 1) (see d08b25f and in the PR). This way the arguments were dispatched possibly multiple times, which is problematic if they have side-effects (see atomic_load_n_sideeffects.c).
• We put everything inside an atomic-block. However, not everything is guaranteed to be executed atomically, e.g. for __atomic_store_n(&x, expr1, expr2) only the actual write on x is atomic, not the evaluation of expr1 or expr2. This could have led to missed data-races (see atomic_memory_order.c)
• We considered the read and write to be atomic for __atomic_load, but only the read should be atomic (fixed in f2e474d)

To fix these issues, the PR adds an interface IPointerReadWrite (and two implementations) that allows to get the dispatched argument, a read and a write separately (s.t. we can "control" the atomicity) and that guarantees that the dispatch is only done once. This interface is the used in StandardFunctionHandler for the translation of atomic functions.

To fix these issues, the PR adds three separate method to ExpressionResultTransformer:

• dispatchPointerLValue to dispatch the pointer expression, but tries to produce LocalLValue
• makePointerAssignment writes to the given address, produces simple assignment for LocalLValue and write-call for HeapLValue
• readPointerValue reads from the given address, always returns an aux-var as RValue, assigns the LocalLValue to the aux-var or reads to the aux-var from the memory for HeapLValue

[maul-esel]

Thanks for making sure these functions work correctly!

I took a look, and it seems a good change. I was not able to check every atomic function in precise detail though. I left some comments on the general mechanism, mostly asking for documentation / explanation.

[schuessf]

Also, just for my understanding: Could you explain how the two classes implementing this interface differ from HeapLValue vs LocalLValue ? Do we need both distinctions?

@maul-esel This interface was not really necessary, HeapLValue and LocalLValue are sufficient for distinction.
Therefore I replaced this interface with separate methods and also added some documentation.
So please review this PR again.