system/system: add config SYSTEM_SYSTEM_DUMPINFO

[CV-Bowen]

Summary

In some cases, applicationes use system() to excute the nsh command, but it's hard to find out who used the system function to execute the nsh command, so add this config to print the call backtrace and the command content.

Impact

system command

Testing

sim

[nuttxpr]

[Experimental Bot, please feedback here]

No, the PR summary does not meet the NuttX requirements.

Here's why:

• Missing Details in Summary:
  • Why is the change necessary? The summary mentions difficulty in debugging, but doesn't explain why this is a problem that needs solving. What specific issues does the lack of backtrace information cause?
  • What functional part of the code is changed? Be specific. Mention the files/modules where you added the config option and backtrace logic.
  • How does the change work? Briefly describe the mechanism used to print the backtrace (e.g., using a new configuration option).
• Incomplete Impact Assessment:
  • Impact on User: Will users need to enable this config option? Will they see the backtrace output by default?
  • Impact on Build: Does this config option change the build process in any way (e.g., new dependencies)?
  • Other Impacts: The other sections (documentation, security, compatibility) are not addressed at all.
• Insufficient Testing Information:
  • Build Host(s): Provide details about your build environment (OS, CPU architecture, compiler version).
  • Target(s): Be specific about the architecture and board configuration you used for testing.
  • Testing Logs: The placeholders for testing logs need to be replaced with actual output. Show the difference in behavior before and after your changes.

To improve the PR:

1. Expand the Summary: Provide a clear and concise explanation of the problem, the solution, and how it works.
2. Complete the Impact Assessment: Address all the impact points, even if the answer is "NO" (in which case, briefly explain why).
3. Provide Detailed Testing Information: Give specific details about your testing environment and include relevant logs demonstrating the functionality.

Remember: A well-written PR makes it easier for maintainers to understand and review your changes, increasing the chances of your contribution being accepted.

[xiaoxiang781216]

let's ignore macOS ci temp break.