Axon: improve channel name handling

[h-mayorquin]

Two improvements to the channel names in AxonRawIO:

1. Names are decoded to str with their real content preserved. They were previously kept as bytes and space-stripped with .replace(b" ", b""), which also destroyed interior spaces, so "IN 1" came back as "IN1". Now only the fixed-width padding is stripped, interior spaces are kept, and decoding uses errors="replace" so an odd byte can never crash the read.

2. A channel whose stored name is blank now falls back to a positional ch{id} instead of an empty "" that left the channel unaddressable.

The protocol path (sProtocolPath) is decoded to str the same way, since as raw bytes its str() baked a "b'...'" literal into the path.

One intended behavior change: files whose channel names contain interior spaces now report the real name, for example File_axon_6 and File_axon_7 return "IN 1" instead of "IN1". The space is part of the name Clampex recorded, so this is the correct value; any downstream code that matched the old space-stripped form should use the real name. The blank-name case is covered by the fixture abf1_episodic_empty_channel_name.abf.

This is also ready @zm711

[zm711]

I know your argument is that we should return them correctly, but is there really no way for us to think about backward compatibility for people who used to use Neo. I would probably tend to agree with you and that people just need to adapt their previous Neo code to fit with the machine convention, but just trying to brainstorm.

[h-mayorquin]

I know your argument is that we should return them correctly, but is there really no way for us to think about backward compatibility for people who used to use Neo. I would probably tend to agree with you and that people just need to adapt their previous Neo code to fit with the machine convention, but just trying to brainstorm.

I have been thinking about this, not only with channel names but with stream ids as well. Thanks for making me overcome the energy barrier and write this down here:
#1879

Check it out, I have a concrete proposal so we can move forward with changes like this and also solve old issues regarding the contract of the API. I would like to hear your thoughts.

[zm711]

I think with your proposal I'm okay with going forward with this and once we have approval from the group we can think about implementing this translation layer.

[zm711]

One last question. I remember on the spikeinterface side we had some formats that failed with 'utf-8' decoding. Is there a failure possibility here using this type of decode? Or the replace guarantees this will always work?