Consider eventual move to Python freethreading

[jay0lee]

https://docs.python.org/3/howto/free-threading-python.html

We should consider eventually moving to Python free threading. This means the infamous Python global interpreter lock (GIL) is disabled and can offer better performance on modern multi-core hyper threading systems. A few points:

• Python free threaded won't be official until Python 3.14 which is due Oct 7th.
• Free threaded support is experimental in Python 3.13 and the cffi library which cryptography uses, which we use has already stated 3.13 is incompatible. https://github.com/python-cffi/cffi/releases/tag/v2.0.0
• lxml doesn't offiically support free threading yet and a bunch of warnings are thrown if it's used. https://bugs.launchpad.net/lxml/+bug/2111289 - we can disable the warnings by setting PYTHON_GIL=0 in the environment. https://github.com/GAM-team/GAM/blob/d50b5fb61e15e8371d01696d75dede7bee5d8d8d/.github/workflows/build.yml#L201
• Since GAM7 code is pure Python, it's unlikely we need to make any changes to GAM7 code itself.
• Currently we are testing free threaded with Python 3.14 dev on Ubuntu 24.04 only. Ultimately we'll want to test on MacOS, Linux and Windows before possibly making it the default. https://github.com/GAM-team/GAM/blob/d50b5fb61e15e8371d01696d75dede7bee5d8d8d/.github/workflows/build.yml#L133-L138

Overall, it also remains to be seen if there's a performance benefit to free threading for GAM7 itself. A typical GAM7 command spends most of it's time waiting on network I/O (quick API call to Google, relatively long wait for HTTP response, quick processing of JSON responses and output). But some commands can end up parsing a LOT of JSON data and we may benefit there.