Fix handling of points-to flags for memcpy in Steensgaard

[phate]

1. Fixes the handling of flags for memcpy in Steensgaard. The method ignored flags so far.
2. Added a unit test that exposes the problem
3. Some minor adjustments for debugging Steensgaard

Closes #334

[haved]

I might be missing something, but isn't the flag copying one level too shallow? See comment

[haved]

I think the code still accidentally applies flags from the addresses. I was wondering if target location unification doesn't automatically merge the flags of locations pointing to the unified locations?

If a->x and b->y, with b being marked as pointing to escaped/external and x and y get unified, will that operation automatically mark a as pointing to escaped/external?

[haved]

Within the current framework of flags, this makes sense. I'm still a bit unsure about what happens when locations don't know about pointing to escaped until propagation, when you have

s -> a -> u
d -> b -> u

And then a turns out to escape later due to s being returned or otherwise leaving the module. Then u also escapes due to propagation, but b is not marked as pointing to escaped. Does b however need to be marked as escaping, or is it enough to have one pointer to u being marked as PointingToEscaped?

[phate]

I will overhaul this PR tomorrow. As written above, it currently is not properly working.

[phate]

@haved : I updated the memcpy analysis. Could you have a look at it again, please?

[haved]

Looks good, this seems like a safe fix for handling late propagation. It would be interesting to see if this would continue to be an issue if the flags were on the pointee location, and not on the pointing location, but such a redesign might introduce other issues I haven't thought about