python 3.14 and free-threading

[ericbuehl]

near as I can tell there is no shared state that requirers the GIL to lock around. this PR:

• declares the gil is not needed
• removes deprecated PyUnicode_READY
• tests and builds on python 3.13t, 3.14, 3.14t

closes #35

[MKuranowski]

Oh nice, so nothing needs to be done to add support for free-threading? Just out of curiosity, what patterns would usually require changes for free threading?

As for PyUnicode_READY - reading the documentation for it, it was definitely needed on 3.9. While it was marked as deprecated in 3.10, I think it's still possible that other modules (readers) used the deprecated functions to create strings. It's a guaranteed no-op only starting with 3.12.

I know that 3.9 is now EOL; it's fine to just drop support for it (but PyUnicode_READY would need to stay until 3.11 is EOL). The code still has some older leftovers from 3.8 support, and I vaguely even remember that it might be possible to restrict aiocsv to the limited C API starting with 3.10.

[ericbuehl]

I created another PR to address the dropping of 3.9: #37

as for gil-free, I'm pretty new, but going off of this guide: https://py-free-threading.github.io/porting/

[MKuranowski]

To me it looks like there were actually 2 things that could be problematic:

• concurrent access to ModuleState* - but all operations are read-only and don't mutate anything, so that's fine
• concurrent access to Parser* - especially the raw memory it allocates - one thread could be reading from that memory, while another could be re-allocating it, causing a use-after-free. I've added a check to ensure parser instances are not shared across threads, as that would be bonkers anyway.