Lazy handling and saving of timestamps (and remove load_from/save_to folder_metadata)

[alejoe91]

In the direction of #4671, this PR starts by rmeoving the unused mechanism to save to / load from metadata.

In addition, this PR also fixes saving timestamps in proper binary format.
For recording objects, the _extra_metadata_to_folder was saving timestamps to npy files, but this is now handled by the write_binary and BinaryRecordingExtractor, which writes in chunk to proper binary files. The binaryRecordingExtractor acceprs a file_timestamps_path with the location of the raw timestamps. Note that this is absolutely necessary for chronic data, since the old version was saving the entire timestamps array with numpy and this cannot be done with very long recordings. Old datasets are handled with the _handle_extractor_backward_compatibility.

To further cleanup, this PR adds save_properties_to/load_properties_from_binary_folder to remove duplicated code for saving and loading properties to numpy arrays.

The cross serialization check was extended to always run against major past versions, to test a recording with timestamps, and to save recordings in parallel for zarr/binary_folder.

[alejoe91]

@chrishalcrow my feeiling was correct: in-memory timestamps are not propagated when saving in parallel...I'll propose a fix.

[chrishalcrow]

Now, the time_vector of a FrameSliceRecording is the time vector of the parent: e.g. the full recordings time_vector.

But if you save a FrameSliceRecording as a binary file, it will save using get_times.

So if you load the sliced recording, this will have the reduced time_vector. So the save/load loop doesn't preserve all information.

I think the FrameSliceRecording should have the sliced time vector? This should still work lazily with memmap?

[alejoe91]

this is correct because the save dumps a snapshot of the current state. I rewrote the logic to make it clearer though