Use probeinterface's renamed Neuropixels readers and new probe detectors

[h-mayorquin]

probeinterface renamed read_openephys to read_openephys_neuropixels (SpikeInterface/probeinterface#427) and read_spikegadgets to read_spikegadgets_neuropixels (SpikeInterface/probeinterface#440) to make the Neuropixels-only scope of those readers explicit; the old names remain as deprecation aliases. The same two PRs add detectors has_neuropixels_probes(settings_file, stream_name=...) and has_spikegadgets_neuropixels_probes(file) that parse the settings XML / .rec header and return whether the recording carries any Neuropixels probe geometry.

This PR switches the OpenEphys and SpikeGadgets extractors to call the new names and gates probe attachment on the detectors. Previously both readers were called unconditionally with raise_error=False, so a recording that legitimately had no Neuropixels probe (Intan / Rhythm FPGA / NI-DAQmx for Open Ephys, tetrodes / ECU for SpikeGadgets) silently returned None and the extractor finished probe-less. With the detector check up front the no-probe path is a normal control-flow branch, and any real parsing error from the reader now surfaces instead of being swallowed.
I
I am also removing the version guard and the packaging import, since pyproject.toml already pins probeinterface>=0.3.2.

[chrishalcrow]

Hello, this PR demonstrates an awkward difference between uv and traditional python venvs.

uv checks all dependency groups and prioritizes git repos over pypi releases. E.g. if you run uv run ... uv will create a venv with probeinterface from source, since this is in common-tests
If you make a venv and pip install spikeinterface from source from this PR, the resolver completely ignore common-tests and installs probeinterface v0.3.2.

The new functions are only in probeinterface main. So if you try to load a openephys neuropixel recording with a uv generated venv, it's fine. If you do it with a pip installed venv, it errors.

Just wanted to point it out!