Implement more precise memory analysis for LoopIR.Free

[yamaguchi1024]

This PR updates the insertion of LoopIR.Free from

for ...:
  x : R[...]
  ....
  free(x)

to

for ...:
  x : R[...]
  x = ...
  z = x * ... # last use of x
  free(x)
  ....

[gilbo]

I'm still not clear on why we would want to make this change. @alexreinking ?

@yamaguchi1024 If the concern here is that you want to be able to reclaim previously used memory, then we should probably do this a different way. One possibility is to do some kind of aggregate static allocation because we can determine that ahead of time. Another possibility (for whatever specific code is prompting this change) is to manually re-use the memory in question. (we even have one scheduling primitive designed to help do that)

Since the user can't currently control where Free is inserted, the chosen policy ought to somehow be universal. I'm not clear on why this change to Free insertion would be universally better, nor why there isn't a universally optimal solution (which would suggest that we need to expose this to users instead...)

[yamaguchi1024]

@gilbo Because users cannot control where Free is inserted, I think Free insertion logic should be as tight as possible. In general, I don't think we want to hold a memory allocation that is not used until the end of the scope.

[alexreinking]

I think this is the right thing to do in the absence of user scheduling for frees. I didn't check the algorithm here super carefully, but I'm a little surprised none of the golden outputs changed.