Add support for pathlib.Path in the Transport interface

[sphuber]

Currently, that is not officially supported and there are differences between the implementations. For example LocalTransport.isfile accepts (not explicitly) pathlib.Path instances, but SshTransport does not. Now that pathlib is so common, we should provide generic and consistent support for it.

[chrisjsewell]

@sphuber I note that although pathlib.Path is correct locally, it's not technically correct for ssh and should be a PurePath, i.e. not linked to the local file system (https://docs.python.org/3/library/pathlib.html)

Even using PurePath and not PurePosixPath is a bit sketchy because:

Depending on your system, instantiating a PurePath will return either a PurePosixPath or a PureWindowsPath object

So it kind of assumes that you are working on a posix machine and that the remote computer is also a posix machine

I note this, because I saw discrepancies of this sort have been introduced in e.g. #5664, where InstalledCode.get_executable -> pathlib.Path, even though InstalledCode.filepath_executable -> pathlib.PurePath

Related, I don't think any of these new files have been added to the mypy type checking (in .pre-commit-config.yaml), which is currently opt-in (per-file) and should really eventually move to opt-out, covering everything by default

[sphuber]

Fair point, but at the very least the arguments that refer to files on the local file system should support it. We can discuss whether relative file paths that model paths on the remote should be representable by PurePaths or not. As you say there are pitfalls, but the current interfaec already does the same, but simply uses strings. This in a sense is worse, because a user now has to literally hard code for example the slashes in the path. The current implementations assume forward slashes, but it would be better to generalize this with pathlib.Path. The implementation will simply have to convert those to whatever is proper for the remote that it is modelling.