Clarify whether `contact_ids` must be unique across probes in a ProbeGroup

[h-mayorquin]

The code comment in Probe.__init__() and the set_contact_ids() docstring both state that contact_ids must be unique at both the Probe and ProbeGroup level. However, cross-probe uniqueness is not enforced. The check was originally present but was intentionally removed in #229 (Oct 2023), while the documentation and comments were never updated to reflect this change. The method check_global_device_wiring_and_ids() only validates device_channel_indices despite its name suggesting it also covers IDs.

Currently, generate_dummy_probe_group() produces duplicate contact_ids across probes, and combining two same-model probes (e.g., two NP1.0 via read_spikeglx()) results in ambiguous IDs like "e0" appearing on both. This is misleading and might conflict with downstream code that uses contact_ids as lookup keys (such as BIDS contact table joins). On the other hand, the decision to remove cross-probe enforcement was probably taken for good reasons in #229, but those reasons are not documented.

We should decide on one of two paths: either restore and enforce cross-probe uniqueness (updating generate_dummy_probe_group(), readers, and combine_probes() accordingly), or update the comments, docstrings, and method name to reflect that contact_ids are only unique within a single Probe. If we go the latter route, maybe we should drop the idea of "id" and just call them contact_name? Related: #263, #229.

[samuelgarcia]

I think we should stay with the concept of contact_ids unique at probe level and uniqueness at probegroup level is (probe_index, contact_id) and we should enforce it.
A classic usecase is to dowload 2 times the same probe and put then in probegroup, doing this we do not expect contact_ids renaming, i think.
no ?