gcov: Solve the problem of incorrect report generation caused by different compilation and test environments

[W-M-R]

Summary

Due to the makefile, the relative paths of the files are different, and it is impossible to use existing tools such as gcov and lcov to specify a base compilation path for them.
The solution for Linux is to copy a copy of the source code from the compilation environment to the test environment, and there is a place that is consistent with the absolute path of the compilation environment.
This solution is to pass in the "-b" parameter to directly modify the info file generated by lcov. The search path will be executed in the next step of genhtml

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]

Does this PR meet the NuttX Requirements? Please be concise

The PR as described does not fully meet the NuttX requirements. While it addresses a specific issue with code coverage tools, the provided information lacks crucial details needed for proper review.

Here's a breakdown:

Missing/Insufficient Information:

• Summary: While the problem is stated, the "how it works" part is vague. "Passing the -b parameter to modify the info file" isn't sufficient. Explain what -b does, how it modifies the info file, and why this solves the relative path issue with gcov/lcov. What part of the Makefile caused the issue in the first place? Was modifying the Makefile considered? Why was this approach chosen over other potential solutions?
• Impact: The Impact section is entirely placeholder text. This needs to be filled out. Does this change affect any users directly? Does it change the build process (besides adding a flag)? Does it have any implications for different architectures or boards? Does it require documentation updates?
• Testing: The Testing section is also placeholder text. Specify the host OS, CPU architecture, compiler used, and the target architecture and board configuration. Crucially, provide actual before and after test logs. Demonstrate that the code coverage tools were not working before and are working correctly after the change. Include specific examples of the paths that were causing issues and how they are resolved. Quantify the improvement if possible (e.g., "Code coverage increased from X% to Y%").

Recommendations to meet the requirements:

1. Elaborate on the solution: Provide a detailed explanation of the -b parameter and how it modifies the lcov info file. Show examples of the problematic paths and how the fix corrects them.
2. Justify the approach: Explain why modifying the lcov info file was chosen over other potential solutions, such as modifying the Makefile or using absolute paths in the source code.
3. Complete the Impact section: Address all the points in the template. Even if the answer is "NO," explicitly state it. For example: "Impact on user: NO. This is a developer-focused change and does not affect end-users."
4. Provide detailed testing information: Specify the host and target environments used for testing. Include actual before-and-after test logs demonstrating the issue and the fix. Show concrete examples of the paths, the errors encountered, and the corrected behavior.

By providing this missing information, the PR will be much more likely to be accepted.