arm/rp2040,rp2350: Allow configuring XOSC startup delay, and set similarly to pico-sdk

[ids1024]

Summary

On some boards, the 1ms startup delay for the XOSC isn't sufficient, and NuttX can fail to start. (Depending on how the board was was reset.) To fix this, the delay has to be increased of affected boards, so this adds a configuration in board.h.

raspberrypi/pico-sdk#457 changed this in pico-sdk, and talks a bit about why this is needed.

Impact

For the Adafruit RP2040 boards and the Seeed XIAO, affected boards should now boot properly. At the cost of about 64ms delay on start.

Behavior should be entirely unchanged on other boards.

Testing

• adafruit-feather-rp2040:usbnsh works on my unit before and after this change; so the one I have isn't affected, or it's very intermittent
• I needed this fix for NuttX to start properly on power on reset or when plugged in on my Feather RP2350. I'll be opening another PR to add that board.

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the NuttX requirements, although some sections could be expanded for clarity.

Strengths:

• Clear Summary: The summary explains the "why," "what," and "how" of the change. The link to the pico-sdk PR provides valuable context.
• Impact Addressed: The impact section covers several key areas (user, hardware, compatibility).
• Testing Provided: Testing results are included, although they could be more robust.

Areas for Improvement:

• Summary: While the summary is good, explicitly mentioning the new configuration option added to board.h would be beneficial. For example: "This PR adds a CONFIG_RP2040_XOSC_STARTUP_DELAY_MS configuration option in board.h to allow boards to specify a longer startup delay for the XOSC."
• Impact: While the impact on the user, hardware, and compatibility is mentioned, several sections are marked as "NO" without explanation. Even if there's no impact, explicitly stating "NO - No change to the build process" is better for clarity. The impact on documentation should be addressed – does this new config option need to be documented? Security and forward/backward compatibility implications should also be explicitly addressed, even if the answer is "NO - No security implications."
• Testing: While testing is provided, it's limited. Ideally, you'd provide logs demonstrating the failure before the change and the successful boot after the change. The current testing description suggests the initial board works, making the test less convincing. Find a board that consistently exhibits the failure to showcase the fix effectively. Include specifics of the build host (OS, compiler version). Clearly state which target architecture and board configurations were tested.

Example of Improved Testing Section:

Testing:

Build Host(s): macOS Ventura 13.5, clang version 14.0.6
Target(s): arm, adafruit-feather-rp2040:usbnsh, seeed-xiao:nsh

Testing logs before change (adafruit-feather-rp2350 -  Note: This board will be added in a separate PR):

```

Testing logs after change (adafruit-feather-rp2350):

<Insert log showing successful boot here>

Testing logs before/after change (adafruit-feather-rp2040, seeed-xiao): (Note: These boards did not exhibit the failure consistently but were tested to ensure the change did not introduce regressions)

<Insert relevant portions of logs, focusing on XOSC initialization>

By addressing these points, the PR will be even stronger and easier for reviewers to assess.