Add compatibility with NP2020 probes

[chrishalcrow]

As per #432, there are some small changes to the imro format. Primarily, probe_type is no longer being used. We will keep it in read_imro in case users have constructed custom imro files for their own setups and are using the probe type key.

In this PR, I remove an unnecessary cast to int for the probe type (in the _parse_imro_string the cast value was never used. In read_imro it was immediately cast back to string). This allows the new imro files to be read without any other changes (nice!!).

Then I add some test data, supplied by @jenniferColonell and @billkarsh (thanks!)

[billkarsh]

SI must be able to parse SpikeGLX data with either the 'old' imro format that has a type code, or the new with pn. It isn't just custom made imros that may have type codes. All SpikeGLX made data before version 20260115 will have type codes, which will be 95% of all data for a long while because people don't update software very often. So any imro reader needs to accept and parse either format. Look at the first item in the imro header as a string. (1) If it starts with a non-number (doesn't have to be an 'N') assume it is a pn. If you wish to validate the imro compatibility, this pn should match the pn in the metadata (which must also exist). Interpret the imro data according to the format spec for that pn in the probe table. (2) If the imro header value is a pure number it is a type code and this can be handled as you had been. Case (2) is now the 'legacy' case even though it will dominate for many months.