Maximize compatibility with `pathlib.Path` about path

[jaraco]

Nice. Sounds good. I welcome the contributions. In cases where the functionality is duplicative and the pathlib syntax is inarguably as good, let's also deprecate any local pecularities.

[jaraco]

In #218, I'm working on adding support for .suffix, .with_stem, and .with_name.

[jaraco]

Looks like link_to was replaced by hardlink_to and removed.

[jaraco]

I'm looking at symlink_to and hardlink_to, and it's interesting. pathlib's implementation is very different, switching the order of arguments. It's not obvious why the order of arguments was switched (from os.path equivalents) and in fact, the order was only switched in symlink_to originally and later in hardlink_to. I'm not sure yet if the other ones should be deprecated. I'm leaning toward keeping them for now.
Another difference is that pathlib doesn't return anything for symlink_to or hardlink_to, but the path implementation does. It seems to me that returning something would be useful, but I'm yet unsure what is best to return. I'll probably start with not returning anything at all (matching the pathlib behavior) unless there's a case to be made for a returned value.

[jaraco]

I observe that Path.owner and pathlib.Path.owner() are incompatible. It won't be possible to align those without first deprecating .owner.