Puma and Lite CRP handle old table indexes inconsistently

[axch]

Consider a CRP whose current set of assignments is 1, 1, 3 (to wit, 2 had been assigned before, but was moved by inference). If the CRP is to emit a new table assignment, it could reasonably produce 2 or 4. Is one or the other definitely right? In any case, Puma and Lite disagree on this point (enumerate method consistency is #356).

[lenaqr]

Lite tries to reuse old indices, presumably so that unapply/reapply will give the same one, but even Lite's implementation has some unspecified behavior; it stores empty indices in a Python set, so the next index you pop from the set might be nondeterministic. I've thought before that maybe it should be a stack instead so that you get them back in exactly the reverse of the order that they were unassigned.

[axch]

This impinges on #470.