Cherry-pick changes for release 3.3

[julianuziemblo]

destroy_dev() is a counterpart to create_dev() that allows for device removal without sending messages back to the calling port unlike remove()/unlink() functions

YT: RTOS-1254
(cherry picked from commit 098f27b)

Description

Motivation and Context

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (refactoring, style fixes, git/CI config, submodule management, no code logic changes)

How Has This Been Tested?

• Already covered by automatic testing.
• New test added: (add PR link here).
• Tested by hand on: (list targets here).

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing linter checks and tests passed.
• My changes generate no new compilation warnings for any of the targets.

Special treatment

• This PR needs additional PRs to work (list the PRs, preferably in merge-order).
• I will merge this PR by myself when appropriate.

[gemini-code-assist]

Code Review

This pull request introduces the destroy_dev function to handle the removal of device nodes. The implementation includes canonical path construction and a manual path walk to send an unlink message to the device filesystem. Feedback identifies a bug in the retry logic for devfs lookup, suggests sharing the nodevfs state at the file level for consistency, and points out a redundant lookup call that could be optimized by integrating it into the existing path walk.

[adamgreloch]

Note that now you are submitting a cherry pick that doesn't reflect master changes due to the < 3 ~> > 3 fix

[julianuziemblo]

Note that now you are submitting a cherry pick that doesn't reflect master changes due to the < 3 ~> > 3 fix

Yeah, unfortunately I can't submit this change separately to master as it is overwritten on the next commit that I don't wanna submit here... Maybe this should be a separate commit with a fix, without "cherry picked from" ?