Add Python version support policy

[dangotbanned]

Originally posted by @dangotbanned in #2084 (comment)

Personally, I'd like to drop 3.8 support now and at the same time introduce a Python version support policy (e.g. python/typing_extensions#571).
My suggestion for that is to keep it simple and stick to EOL support - which is what most of the (upstream) backends do anyway.
We can always extend this to avoid breaking downstream but I think documenting it 5 months ahead of 3.9 EOL will leave plenty of time to prepare CI workflows 🤞.

I'm open to any other ideas, just hoping to move this issue along if possible 🙂

It doesn't need to be anything huge and can mostly just point towards the dev guide calendar.
We can also borrow some rationale from SPEC 0 — Minimum Supported Dependencies, if needed.

The novel part will be explaining how this interacts with our Perfect backwards compatibility policy.
Currently, that page doesn't mention python at all which may be fine from a narwhals-perspective but could cause confusion if someone assumed we support all versions of python indefinitely 😅

[dangotbanned]

This section of SPEC 0 covers pretty much everything

Motivation

Limiting the scope of supported dependencies is an effective way for packages to limit maintenance burden. Combinations of packages need to be tested, which impacts also on continuous integration times and infrastructure upkeep. Code itself also becomes more complicated when it has to be aware of various combinations of configurations.

Adoption of this SPEC will ensure a consistent support policy across packages, and reduce the need for individual projects to divise similar policies.

Ultimately, reduced maintenance burden frees up developer time, which translates into more features, bugfixes, and optimizations for users.

An extra specific is that there is an environmental cost to our CI.
I'm not pretending I can quantify it 😅, but each run we do in an attempt to preserve 3.8 compatibility adds to it