Refactor BlackRock spec specific functions

[h-mayorquin]

I worked on Blackrock today because of issue #1755 plus another user problem that we encountered on the past NWB workshop and there is an improvement I would like to make.

The current codebase uses generic variant names (variant_a, variant_b, variant_c) throughout the BlackrockRawIO implementation, making it difficult for developers to understand which Blackrock file specification version each function handles. When debugging or maintaining code, developers need to:

1. Look up mapping dictionaries to understand what variant_a means
2. Cross-reference specification versions with variant letters
3. Remember arbitrary letter-to-version associations

I think is better to get rid of the arbitrary a, b and c and just include the specification directly on the name:

- variant_a → spec_v21 (handles specification 2.1)  
- variant_b → spec_v22_30 (handles specifications 2.2, 2.3, and 3.0)  
- variant_c → spec_v30_ptp (handles specification 3.0 with PTP timestamps)  
- Special cases: spec_v21_22 and spec_v23 for NEV data functions with specific version ranges  

Debugging then becomes easier because the function name directly shows the specification context with the intent clear from the function signature alone.

All of these are private functions so no problem with internal name changing (god bless private functions)

What do you think?

[zm711]

This makes sense to me!

[zm711]

You good with me merging this? Or any other tweaks you want to make?