Add a bug future for returning records from functions

From return-record.future:

bug: records being returned from functions are not handled properly

There are two bugs here, depending on if the return type from the function is
inferred or not. Both cases should eventually do the same thing.

When the return type is inferred (baz in this test):
  =(...) is not called when assigning to the return variable, and a PRIM_MOVE
  is used instead. This causes a bitwise copy in the generated C, including the
  pointer to a 'helper' instance. So when the local Zed is destroyed on leaving
  the function, the pointer in the returned value becomes invalid.

When the return type is specified:
  =(...) is correctly called in this case, but both the left and right hand
  sides of the assignment are deallocated before returning. Only the right hand
  side should be deallocated.

So we either need to perform the move into the return temp, and not destroy it
before returning (this would be faster, but I'm not sure it if will miss some
edge cases), or we should only destroy the rhs of the =(...) before returning.

To make this bug easier to observe, I recommend setting M_PERTURB (glibc),
MallocScribble (osx), MALLOC_OPTIONS=J (bsd), or whatever the relevant setting
for your implementation of malloc/free is to write a value to any freed memory.
Merge pull request #894 from Kyle-B/kb-add-record-return-bug

Add a bug future for returning records from functions

From return-record.future:

bug: records being returned from functions are not handled properly

There are two bugs here, depending on if the return type from the function is
inferred or not. Both cases should eventually do the same thing.

When the return type is inferred (baz in this test):
  =(...) is not called when assigning to the return variable, and a PRIM_MOVE
  is used instead. This causes a bitwise copy in the generated C, including the
  pointer to a 'helper' instance. So when the local Zed is destroyed on leaving
  the function, the pointer in the returned value becomes invalid.

When the return type is specified:
  =(...) is correctly called in this case, but both the left and right hand
  sides of the assignment are deallocated before returning. Only the right hand
  side should be deallocated.

So we either need to perform the move into the return temp, and not destroy it
before returning (this would be faster, but I'm not sure it if will miss some
edge cases), or we should only destroy the rhs of the =(...) before returning.

To make this bug easier to observe, I recommend setting M_PERTURB (glibc),
MallocScribble (osx), MALLOC_OPTIONS=J (bsd), or whatever the relevant setting
for your implementation of malloc/free is to write a value to any freed memory.