Expose `os.DirEntry` objects from pathlib

[barneygale]

Feature or enhancement

I propose we add a new Path.status attribute that stores an os.DirEntry object in paths yielded from Path.iterdir(), or a pathlib-specific type with a similar interface in other paths.

This would:

• Allow users to access to the cached os.DirEntry after calling Path.iterdir(), which is useful for efficiently determining files' types and often doesn't involve a system call.
• Allow users to switch on the type of any path without repeatedly making system calls, or having to resort to S_ISREG(st.st_mode) and other holy incantations.
• In the pathlib ABCs, allows us to entirely banish PathBase.stat() and the stat_result interface, which is too low-level and local filesystem-specific

See discussion: https://discuss.python.org/t/is-there-a-pathlib-equivalent-of-os-scandir/46626

Linked PRs

• GH-125413: Add pathlib.Path.dir_entry attribute #125419
• GH-125413: pathlib.Path.copy(): get common metadata keys only once #125990
• GH-125413: Add pathlib.Path.scandir() method #126060
• GH-125413: pathlib ABCs: use scandir() to speed up glob() #126261
• GH-125413: pathlib ABCs: use scandir() to speed up walk() #126262
• GH-125413: pathlib: use scandir() to speed up copy() #126263
• GH-125413: Revert addition of pathlib.Path.scandir() method #127377
• GH-125413: Add pathlib.Path.info attribute #127730
• GH-125413: Move pathlib.Path.copy() implementation alongside Path.info #129856
• GH-125413: Add private metadata methods to pathlib.Path.info #129897
• GH-125413: Add private pathlib.Path method to write metadata #130238
• GH-125413: pathlib ABCs: use caching path.info.exists() when globbing #130422
• GH-125413: Fix stale metadata from pathlib.Path.copy() and move() #130424

[ncoghlan]

I put this feedback on the PR, but it's probably better placed here: while I like the general idea, I don't think this specific API is the right way to do it.

• dir_entry potentially being None based on how the instance was created is inconvenient
• the docs having to excuse dir_entry existing on PurePath objects is awkward

I think we can eliminate both of those bits of awkwardness:

• define a new alternative construction method on os.DirEntry objects that allows one to be created from arbitrary os.PathLike objects
• make the slot on PurePath private rather than public (presumably as _dir_entry)
• define PathBase.dir_entry as a read-only property that returns the cached entry if it is already set, otherwise it uses the new constructor API to create a cached DirEntry instance for itself

If it's impractical to add os.DirEntry.from_path, then a pathlib._DirEntry class that just emulated the os.DirEntry API based on the real underlying Path object would also be fine