[MNT] make pyproject.toml pip compatible

[fkiraly]

The current pyproject.toml can only be read by poetry, not by pip.

This is a serious limitation to users and developers, since it forces them to use poetry.

This PR moves pyproject.toml to the most widely interoperable format.
This PR does an 1:1 translation, except for removing python 3.8 (which is no longer supported) and adding python 3.13 to the range.

Also:

• updates the docs with references to pip
• lints impacted files

[dswah]

I agree with using a pip-first standard.

However

• i would like pyGAM to continue to carefully calculate dependency compatibilities to avoid failing installations.
  Is this possible with the current PR?
• do we still need poetry.lock if we no longer use the poetry tool?

[fkiraly]

i would like pyGAM to continue to carefully calculate dependency compatibilities to avoid failing installations.
Is this possible with the current PR?

pip does this by default afaik. If you do pip install (with a requirements file or an explicit list), it will try to find matching dependencies via a resolution algorithm that is the same or similar which uv uses.

We will also do testing on ranges of versions (see #380 as a start of this) to ensure the stated dependency ranges are accurate.

do we still need poetry.lock if we no longer use the poetry tool?

It could be a recommendation for developers, though that is a question, whether we leave it as optional or remove it.

[dswah]

let me check if poetry is mentioned in the docs or readme

[fkiraly]

expected failures on Mac and python 3.13, hopefully fixed by #384 and #372 and #366.

In the interest of time, I would like to merge this soon, and merge this into the aforementioned three PR to see what happens!

[dswah]

@fkiraly ok apologies for the possible mess

• commit should say allow 3.13 (not 3.14)
• i figured we wanted to support 3.13 and test in our CI

[fkiraly]

yes, great! No problem about the commit, it gets squashed, so what goes on main is the description from the top.