Remove prescription of python version / establish a process to keep it up to date

[HarrisonWilde]

As we improve the cookie cutter in other ways, I think the requirement of pinning a certain major version of python could be something to move away from. This could be through encouraging usage of something like pyenv or uv (both good ideas anyway in my opinion) and then ensuring tooling is backwards compatible with some reasonable cut off of say 3.10 given that's been the req up to now.

Otherwise, we should at least endeavour to upgrade versions more frequently. I think in general though it would be helpful to aim for flexibility, very possible we may want to use specific weird version of package at some point in the future that necessitates specific version of python etc.

[caldwellst]

Agree here on not mandating Python version within the cookiecutter. Not so sure about repositories (or projects in a monorepo) not pinning a specific major version. Probably not that common an issue, but at least when working with geospatial dependencies in my last position, resolving dependencies across major versions was a near impossibility.

Maybe that is more of an edge case in our work, but have doubts that our rapid way of development is going to give people time to test and ensure their specific project works across multiple versions. Would expect more that our utilities libraries or mature repos might have this cross-version testing fully setup, but rarer in our smaller projects? Doubly true for analysts and new users to this way of development and programming.

Something to discuss!