xtensa: add parameters to xtensa_pause_handler

[hujun260]

Summary

add parameters to xtensa_pause_handler
nxsched_smp_call_handler need these parameters

Impact

xtensa

Testing

esp32s3-devkit:smp(ostest)

[nuttxpr]

[Experimental Bot, please feedback here]

This PR does not meet the NuttX requirements. Here's why and how to fix it:

Missing Information:

• Summary:
  • Why is this change necessary? Is it fixing a bug, adding a new feature, or an optimization? Be specific.
  • What functional part of the code is being changed? Mention the specific files, functions, or modules affected.
  • How does the change exactly work? Provide a technical explanation of the changes made.
• Impact: You only mentioned "xtensa" under impact. Address all impact categories (user, build, hardware, documentation, security, compatibility) with "NO" or a "YES" + description.
• Testing:
  • Insufficient Detail: "esp32s3-devkit:smp(ostest)" is too vague. Specify the NuttX version, compiler, any configurations used, and how you specifically tested the changes.
  • Missing Logs: You need to provide actual testing logs (both before and after your changes) to demonstrate the problem and the fix.

How to Improve the PR:

1. Expand the Summary: Clearly articulate the problem, the solution, and the technical details of your implementation.
2. Complete the Impact Assessment: Systematically analyze and document the impact on all the listed categories.
3. Provide Detailed Testing Information:
   • List the exact NuttX version, build host OS and tools, target architecture, and board configuration.
   • Describe your testing steps in detail.
   • Include the actual "before" and "after" testing logs.

Example (for the "Impact" Section):

## Impact

* Is new feature added? NO
* Is existing feature changed? YES, the `xtensa_pause_handler` now accepts additional parameters to support the needs of `nxsched_smp_call_handler`. 
* Impact on user (will user need to adapt to change)?  NO
* Impact on build (will build process change)? NO
* Impact on hardware (will arch(s) / board(s) / driver(s) change)? YES, this specifically affects Xtensa architectures.
* Impact on documentation (is update required / provided)? YES, the documentation for `xtensa_pause_handler` needs to be updated to reflect the new parameters. 
* Impact on security (any sort of implications)? NO
* Impact on compatibility (backward/forward/interoperability)?  May impact backward compatibility if existing code relies on the previous signature of `xtensa_pause_handler`.  (Provide more details if applicable).
* Anything else to consider? N/A