Describe the bug
originally here SpikeInterface/spikeinterface#1260
Recordings from SpikeGadgets hardware have two possible channel maps: HWChan (a channel map defined by the amplifier) and Trodes channel map (for displaying on Trodes, the data acquisition software for SpikeGadgets). The mapping between these are in the header of the file that contains the recording (in .rec format). The channel IDs one gets with get_channel_ids from a SpikeGadgetsRecordingExtractor is in the Trodes order (though the channel names are HWChan names), which is sensible. But the order of the traces is completely scrambled (neither Trodes nor HWChan).

To Reproduce

• Get example data here https://ucsf.box.com/s/ah2u2avamtf4hj54mryxqo1kvl09t7tp
• Load it

recording_rec = si.read_spikegadgets('.../20220919_130120/20220919_130120.rec',
                                     stream_name='trodes')

• Download latest version of Trodes https://bitbucket.org/mkarlsso/trodes/downloads/
• this contains a useful util called trodesexport which converts data to binary
• run trodesexport to convert the file to binary:

trodesexport -rec path_to_file.rec -kilosort

• load binary

recording_bin_ks = si.BinaryRecordingExtractor(file_paths='.../20220919_130120/20220919_130120.kilosort/20220919_130120.group0.dat', sampling_frequency=30e3, num_chan=128, dtype='int16')

• compare. e.g. plot the first channel of recording_rec and recording_bin_ks
• extra: to get the channel map info, look in the header of rec file

Expected behaviour
they should match (but they don't)

Environment:
latest version of Trodes and spikeinterface