This partially undoes the intent of https://reviews.llvm.org/D151418 by
cheating its way to keep the "containing op" (aka loop) handle read-only
in fusion. It is crucial to do so for composability of tiling and
fusion. Specfically, after the "containing op" handle started being
consumed, it became impossible to perform additional tiling after fusion
except tiling the last-fused op:
%tiled1, %loop1 = tile %op %producer1, %loop2 = fuse %producer into %loop1 // invalid, because %tiled1 is invalidated by consuming %loop1 // that points to its parent tile %tiled1
or
%tiled1, %loop1 = tile %op %tiled2, %loop2 = tile %tiled1 %p2 = fuse %producer into %loop1 // invalid, because %loop2 is invalidated by consuming %loop1 // that points to its parent fuse %p2 into %loop2
The approach here makes creative use of the state extension mechanism to
update the payload operation associted with the operand handle. Further
investigation is necessary to understand if is consistent with the
overall execution model of the transform dialect, but it is crucial to
restore composability ASAP.