Add std::path::Path::is_empty.

[frewsxcv]

Original issue requesting this feature:
#30259

Originally implemented in #30623
but that pull request when stale.

It was rebased in #31231, but the
Path changes got lost as the focus shifted towards OsString and
OsStr.

An RFC (rust-lang/rfcs#1497) was briefly
opened, since I didn't know if this functionality needed an RFC, but
@alexcrichton clarified in the RFC issue I linked that this is not the
case.

[alexcrichton]

Thanks @frewsxcv! Most operations on Path operate over the components iterator, so I wonder if this also wants to do the same? I'm not sure if more than one path normalizes to "".

I'm not entirely sure what the use case is for this function, but seems fine to add for symmetry?

[alexcrichton]

r? @alexcrichton

cc @aturon

[frewsxcv]

If this does get approved, it might also make sense to add std::path::Path::len. I've personally gone back and forth on whether it makes sense to add these; I'm pretty neutral at the moment. Now that #31608 landed, getting the length and emptiness is pretty easy:

let _ = some_path.as_os_str().len();
let _ = some_path.as_os_str().is_empty();

[alexcrichton]

We discusssed this in the libs team meeting yesterday, and the conclusion was that we probably don't want len and/or is_empty on Path for now. Querying a Path should exclusively go through the components iterator as that's basically how a path is always interpreted. Querying the backing storage can always be done via as_os_str (as pointed out), and that's likely good enough for now.

Put another way, testing whether a path is empty by looking at the length of the underlying bytes is probably "just the wrong question to ask", and instead the components iterator should be queried to see if it's empty.

Thanks for the PR though @frewsxcv!