CQ: Fix Ruff PTH110: os.path.exists() should be replaced by Path.exists()

[echoix]

Ruff rule: https://docs.astral.sh/ruff/rules/os-path-exists/

Ignored the "python/grass/__init__.py" file, as it might be the most critical if there's a chance that there is a slight performance penalty to this higher level function.

[ninsbl]

I made some suggestions using the GitHub Web-UI. So suggested changes are checked by pre-commit...
Most changes replace more os.path usage, to avoid we have to touch those lines again alter. If you feel that is out of scope or interferes with your plans / stategy for introducing more pathlib, please feel free to reject suggested changes.

One thing I noticed in this context is that there is a number of cases where Path(file_path).exists() is preceeded by os.path.join(). I guess once we replace os.path.join by pathlib usage as well, we would have to change the lines again that we modified here. Not sure if ruff would catch that and fix automatically...
So I am wondering if there is an order in which the introduction of pathlib would be most efficient....

[echoix]

Since the amount of changes were really big, fixing all the suggestions for pathlib that are now available (they are better and better as time goes) would be too much (over like 2000 places), I reverted back and stuck to only fixing one single rule. I didn't want to pass my time analyzing if the output is accepted as a Path object vs a string, and the effect on the functions called/calling with that new value. For this one, it is a boolean, and maybe it was converted to a Path object for nothing, but I didn't want to analyze too close.

So, if you feel like adding more to the scope, I don't really mind, but it is an extra risk for a PR on the bigger side.

[echoix]

Oh, seems like there's a place that we will need to revert for a test on macOS

[ninsbl]

Since the amount of changes were really big, fixing all the suggestions for pathlib that are now available (they are better and better as time goes) would be too much (over like 2000 places), I reverted back and stuck to only fixing one single rule. I didn't want to pass my time analyzing if the output is accepted as a Path object vs a string, and the effect on the functions called/calling with that new value. For this one, it is a boolean, and maybe it was converted to a Path object for nothing, but I didn't want to analyze too close.

I see. Fully understand.

[echoix]

Found two things to revert

[echoix]

Ready to review again, checks passing now. And others: sorry for the emails, the new files tab in the web UI doesn't implement batching multiple suggestions

[ninsbl]

There is one file where I earlier overlooked that a path was already a pathlib object. Not sure how important that is in a test...

[ninsbl]

Nice. Not being a software developer by education, I do see the value of annotations even clearer...