Move `sortingcomponents` out of `spikeinterface`

[alejoe91]

sortingcomponents and spikeinterface have different targets (developers VS users) and development pace (fast VS slow).

I suggest factoring out sortingcomponents into its own package.

[zm711]

This would probably be most valuable for us if users of the package freely comment on if they use sortingcomponents (or which components they use) or avoid it completely.

[louiskang]

Replied with a thumbs-down to indicate that I don't use sortingcomponents even though I use spikeinterface extensively

[JoeZiminski]

my only concern would be that it might make versioning confusing e.g. the sortingcomponents spikeinterface uses might change a lot making it hard for the average user to understand what version of the tools they've used to get their results.

[alejoe91]

my only concern would be that it might make versioning confusing e.g. the sortingcomponents spikeinterface uses might change a lot making it hard for the average user to understand what version of the tools they've used to get their results.

I think that spikeinterface should depend on a pinned version of sortingcomponents, and so will the internal sorters implementations. If users install from source, I don't think it'll make things worse: even in the current state it would be hard to pinpoint the exact commit for a run..

[zm711]

We also discussed albeit briefly that there may be some core components (if we ended up moving things) would instead be transferred to spikeinterface proper (e.g. some motion stuff could be moved).