Should `cap-std` have its own `Path` type?

[sunfishcode]

Is it worth defining Path, PathBuf and associated types in cap-std? They could mostly be thin wrappers around their std::path counterparts, but they'd omit several ambient-authority methods: metadata, read_link, read_dir, symlink_metadata, and canonicalize.

[sunfishcode]

I brought up the idea of deprecating the functions in question here, and have now posted a PR to deprecate them.

[sunfishcode]

Sounds like deprecating them is not the way to go here, so I'm now thinking about a custom Path type. A linting system is another option (see also #130).

[sunfishcode]

camino is a neat crate providing a Utf8Path type, which might be nice to use for cap_std::fs_utf8. And of course, it also has the filesystem convenience functions. If cap-std defines its own Path to exclude these functions, and continues following the philosophy of reflecting std as much as possible, that might imply that cap-std should have its own version of Utf8Path too, to similarly exclude these functions.

Approaching this with linting is sounding increasingly sensible.

[sunfishcode]

With the ambient authority linter available now, I think the answer here is that cap-std does not need its own Path.