Record fj cluster sequence to avoid relying on thread-unsafe custom shared ptr

Tested and seems to solve the race condition with fastjet ClusterSequence self-deletion (which depends on a custom shared pointer implemented in fastjet). We already had all the pieces ready to record the ClusterSequence to the event store, which is an easy way to simplify the memory management. This was easy to reproduce by scheduling two grooming algorithms on the same input jet collection in parallel with >1 threads.

The original setting to use the auto-deletion is commented to remind ourselves that we can revert to this if/when fastjet solves the problem. That said, if others e.g. @wbalunas and @delsart agree, we could just use the record and plan not to revert.

Expected to address the following JIRA tickets: ATR-22142 ATR-22774 ATR-22799 ATR-22803