adapt Path::file_stem() function for directories

[hacknus]

This PR addresses #133399 .
This adaptation leads to Path::file_steam() no longer treating directories with dots in the name as files with extensions.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @joboet (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[rustbot]

⚠️ Warning ⚠️

• Pull requests are usually filed against the master branch for this repo, but this one is against stable. Please double check that you specified the right target!

[bors]

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts.

[kadiwa4]

Consider adding a new separate feature with these semantics instead; you can't change the behavior of a stable library feature in a backwards-incompatible way.

There are certainly situations where it is useful to think of directories as having extensions, e.g. *.app/*.bundle/*.framework directories on macOS. So there is probably someone out there who relies on this "quirk" of the function.
Also, this function was previously thought of as a function that only acts on the path and not your filesystem. For example users can assume that it has the same behavior regardless of your current working directory. Just because there is a file/dir at the specified path doesn't mean that that's the same file/dir that the user meant.

[joboet]

As indicated above, this would be a breaking change – we can't do those (at least on this scale) in std, so I'll close this PR. Please feel free to propose a different API for this by opening an ACP.