Fix zarr folder suffix handling

[jonahpearl]

While troubleshooting for #3348, I noticed some odd behavior with zarr-based sorting analyzers. Specifically, in some parts of the code, it seemed like the user would be permitted to pass a folder name with the .zarr suffix included (ie folder=/my/favorite/analyzer/ instead of folder=/my/favorite/analyzer.zarr/). This led to two error cases when using create_sorting_analyzer if the user tried to make a new folder without the suffix:

1. it would be created by create_zarr with the suffix, but then would fail to load directly after because the load_from_zarr function didn't add the .zarr suffix.
2. when checking for the folder's existence when overwrite=True in the beginning of the function, it would not delete the folder (since the real folder has the .zarr extension, but the user's folder arg doesn't). But then later in SortingAnalyzer.create_zarr there is another check for whether the folder exists, and when the suffix'd folder does indeed exist, it raises an error, defeating the point of the overwrite kwarg.

This PR fixes that by:

1. creating a single clean_zarr_folder_name in core_tools.py that will check for a .zarr suffix and add one if there isn't already
2. cleaning the user-provided folder to ensure that if mode="zarr", the folder passed to internal funcs always has .zarr appended. Cleaning happens in:

• create_sorting_analyzer
• load_sorting_analyzer
• merge_units
• save_as
• select_units
• remove_units
• [not copy, since that goes just into memory]

I also added cleaning in SortingAnalyzer.create_zarr() and SortingAnalyzer._save_or_select_or_merge() themselves which might be redundant. Hopefully I didn't miss any other entry points but I haven't extensively tested.

Obviously another solution here would be to insist that the user just put the .zarr suffix on themselves. But I like this way, as it allows for minimal change to a user's code (mode from binary_folder to zarr) and they will get the desired zarr behavior.

[samuelgarcia]

merci.
This look ok.