Raise a clear error on ABF files whose header reports an impossible signal size (integer overflow)

[h-mayorquin]

When an ABF file's header reports more data than the file can actually hold, AxonRawIO does the segment offset and size arithmetic in fixed-width integers that silently overflow, so parse_header() succeeds and reports a garbage (or even negative) signal size. The failure then surfaces far from its cause: a downstream read either crashes deep in the data path with an opaque mmap length is greater than file size, naming neither the file nor the reason, or in the worst case reads out of bounds and hands back wrong data with no error at all. This bit both @luiztauffer and me while writing ABF converters,

This change does the offset and size arithmetic in arbitrary-precision Python integers so it can no longer wrap, and validates the implied data extent against the file on disk during parsing. A damaged header is now rejected at the earliest possible point with an explicit error that names the file and says the header is corrupt or truncated, instead of parsing clean and detonating later (or silently). The error stays within the existing neo exception hierarchy, so callers that already guard their reads keep skipping bad files exactly as before, now with a message that actually explains what went wrong. Regression coverage uses two purpose-crafted fixtures on gin, one inflating the size into an overflow and one carrying a negative length, each asserting the specific error it should produce.