Race in setting mark bits for Immix

The trace object code for immix currently has a race in the case where an object is to be copied (not in the common non-copying case). The waiting thread assumes that the object will have been forwarded, but in fact if space is exhausted the first thread won't have forwarded the object; just marked it in place. Should be trivial to fix. The bug shows up in StickyImmix (where there is much more copying), or in other benchmarks where there is lots of defragmentation. It fairly reliably shows up on a FullAdaptive build (assertions identify the problem) when running dacapo on a quad core.