Docu/gcov: Modify the description and fix the script error

[W-M-R]

Note: Please adhere to Contributing Guidelines.

Summary

Docu/gcov: Modify the description and fix the script error

Impact

Update this section, where applicable, on how change affects users,
build process, hardware, documentation, security, compatibility, etc.

Testing

Update this section with details on how did you verify the change,
what Host was used for build (OS, CPU, compiler, ..), what Target was
used for verification (arch, board:config, ..), etc. Providing build
and runtime logs from before and after change is highly appreciated.

[nuttxpr]

[Experimental Bot, please feedback here]

This PR likely does not fully meet the NuttX requirements based on the provided information. Here's why:

• Insufficient Detail in Impact: The Impact section is essentially empty. It needs to be filled out with specifics. Even if the impact is minimal in all categories, explicitly stating "NO" with a brief justification (e.g., "NO - This is a documentation change only") is better than leaving it blank. The current placeholder comment needs to be removed and replaced with actual impact assessment.

• Missing Testing Information: The Testing section also has placeholder text. It must be updated with specific details about the testing environment and the results. Simply stating "works as intended" is insufficient. Provide concrete details about the host and target systems, and include actual test logs (or links to them) from before and after the change. This is crucial for reviewers to understand how the changes were validated.

To make this PR compliant, address the following:

1. Impact: For each impact category (user, build, hardware, documentation, security, compatibility), explicitly state whether there is an impact (YES/NO) and provide a concise explanation. If there's no impact, briefly justify why. For example, for Documentation: "YES - Updated the description of gcov usage to be more accurate." Or, for Security: "NO - This change only affects documentation and has no security implications."

2. Testing: Replace the placeholder text with specific details. Include:

   • Build Host: OS, CPU architecture, compiler (including version). Example: "Linux (Ubuntu 22.04), x86_64, GCC 11.3.0"
   • Target(s): Architecture, board, and configuration. Example: "sim:qemu-x86_64:nsh"
   • Testing Logs: Include relevant snippets of logs demonstrating the issue before the change and the corrected behavior after the change. If the logs are extensive, consider providing a link to a separate file or pastebin. Even if the change is purely documentation-related, showing the rendered documentation before and after (screenshots or diffs) can be helpful.

By providing the missing information in the Impact and Testing sections, the PR will be much more likely to meet the NuttX requirements and be accepted.