Wrong scheduling because of the lack of memory dependencies

[qcolombet]

Our graph does not model the memory dependencies explicitly.
As a result, if we have a variable is written and read on different
data paths, the scheduler may be unlucky and we read the wrong
version of the variable.

Essentially, if you have:
     A
    / \
write read

The scheduler can produce either:
write A
read A
or
read A
write A

Obviously this does not produce the same output.
Glow intended semantic is that write should happen last, but with
our current algorithm, this is actually possible to fool the
scheduler not to do that.

I'm going to send a PR to show how we can fool the scheduler.

[qcolombet]

Problem illustrated in #1284.

This PR adds two test cases that build exactly the same graph. However, by just changing the order of the creation of the nodes, we can trick the scheduler to produce an invalid schedule.

[qcolombet]

After talking with @nadavrot this morning, we are going to explicit state that save nodes happen after the last use of the related variable. In other words, referencing a variable will always get you the old value.

Similarly we are going to enforce that every variable has at most one save nodes. That way it will remove the ambiguity of which save should happen last (all the others would have been dead because of the other restriction.)

[qcolombet]

As expected while reviewing #1176, I realize that our implicit memory dependencies are going to bite us again during graph partitioning.

The problem there is that the post order visiting methods don't see the memory dependencies edges. So, we will have to do one of the following fix the visiting scheme, come up with targeted fix for the graph partitioning stuff, or model the memory dependencies.

[qcolombet]

Fixed by #1307.