Fix excessive RAM usage of preference comparisons

[timokau]

Description

Previously we stored a view into the trajectory in the preference comparison dataset. This view is a reference to the original trajectory, and therefore keeps it from getting garbage collected for as long as the view exists (i.e., however long the comparison is stored in the dataset).

This is problematic when trajectories are large and long, e.g., in the case of atari (images) with SEALS (long episodes). It can cause the RAM to fill up quite quickly in that setting.

We can fix it by copying the fragments we want to store. That avoids keeping a reference to the original trajectory alive, we only need to store the fragment. The tradeoff is that copying adds some overhead and overlapping fragments are no longer deduplicated.

Testing

I trained atari Pong and verified that the RAM usage remains roughly constant after this change. Prior to this change, it kept increasing until the memory ran out.