Remove duplicate includes across multiple files

[no1wudi]

Summary

This commit cleans up redundant header file includes throughout the codebase.
The changes include:

• Removing duplicate #include directives that were present in the same file
• Consolidating includes that were split across multiple lines unnecessarily
• Removing unused includes that were no longer needed
• Fixing some formatting issues with includes

The changes improve code organization and maintainability by:

• Reducing unnecessary dependencies
• Making include dependencies more explicit
• Following consistent include patterns
• Removing dead code

No functional changes are made - this is purely a code cleanup commit.

Impact

Minor

Testing

GitHub CI

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the NuttX requirements, although it could be improved. Here's a breakdown:

Strengths:

• Clear Summary: The summary explains the what and why of the changes.
• Addresses Impact (briefly): It acknowledges impact, though more detail would be beneficial.
• Mentions Testing: Referencing GitHub CI is a good start.

Weaknesses:

• Impact Lacks Detail: While stating "Minor" is concise, it doesn't fulfill the requirement to address specific impact categories (user, build, hardware, documentation, security, compatibility). Even if the answer is "NO" for most, explicitly stating it is better.
• Testing Lacks Detail: Relying solely on "GitHub CI" is insufficient. While CI is crucial, the PR should mention specific target architectures and configurations tested locally. Providing snippets of relevant logs (even if showing no functional change) adds further confidence.

Recommendation:

To strengthen this PR, expand the Impact and Testing sections. Example:

Impact (Improved):

• Is new feature added? NO
• Is existing feature changed? NO
• Impact on user (will user need to adapt to change)? NO
• Impact on build (will build process change)? NO (Expected to be slightly faster due to reduced parsing, but negligible)
• Impact on hardware (will arch(s) / board(s) / driver(s) change)? NO
• Impact on documentation (is update required / provided)? NO
• Impact on security (any sort of implications)? NO
• Impact on compatibility (backward/forward/interoperability)? NO
• Anything else to consider? This cleanup improves code maintainability and reduces the chance of future include-related issues.

Testing (Improved):

I confirm that changes are verified on local setup and works as intended:

• Build Host(s): Linux (Ubuntu 20.04), x86_64, GCC 9.4.0
• Target(s): sim:nsh, arm:stm32f4discovery:nsh

Testing logs before change (sim:nsh - demonstrating no functional change):

NuttShell (NSH)
nsh> help
... (standard NSH help output) ...

Testing logs after change (sim:nsh - demonstrating no functional change):

NuttShell (NSH)
nsh> help
... (standard NSH help output) ...

By adding this level of detail, the PR becomes significantly stronger and inspires more confidence in the changes.