crashdump change to choice, add coredump to mtd support based on mtdout stream.

[jasonbu]

Summary

Pervious coredump to device based on blk geo information, and not easy to extend,
we changed it to seek api, so the coredump to device should more common, and also possible to mtd directly.
for the small device should be more effeciency. As we don't have to use blk/bch/ftl/mtd. both code size and memory will be decreasd.
Also as we removed the geo information requirments, the alloc of g_blockinfo can be removed.

should work with
apache/nuttx-apps#2871
if want using coredump to blk/mtd -> reboot -> restore to filesystem -> adb/ymodem/.. this kind of workflow.

Kept the compatible with

board_crashdump

API by BOARD_CRASHDUMP_CUSTOM, and it's a choice which exclusive with coredump syslog/blk/mtd.
Should compatible with the current running project/defconfig.

Impact

the coredump infomation position has changed, we now able to put more data in coredump section.
support coredump to mtd (especially norflash)
board_crashdump will not be call if using coredump syslog/blk/mtd.
if we further have more storage device type, will be easier to add support.

Testing

CI-test & local arm-v8m board, local arm-v7a board.

[nuttxpr]

[Experimental Bot, please feedback here]

This PR appears to mostly meet the NuttX requirements, but some areas could be improved for clarity and completeness.

Strengths:

• Clear Summary of "Why": The rationale for the change (simplification, extensibility, efficiency) is well-explained.
• Functional Change Description: The shift from block geometry to seek API is clearly stated.
• Impact Description: The impact on users, build, hardware, and compatibility is addressed, although some areas could be more detailed.
• Testing Information: Mentions CI and local testing on specific architectures.
• References Cross-Project Dependency: Correctly links the related NuttX Apps PR.

Weaknesses:

• Missing Issue References: No NuttX or NuttX Apps issue references are provided, even though the template requests them. If there isn't a corresponding issue, state that explicitly.
• Impact - User Adaptation: While it mentions the core dump information position changing, it doesn't clarify if users need to adapt anything in their applications or scripts to handle this change. Be explicit.
• Impact - Build: While mentioning decreased code size and memory usage, it doesn't detail any build process changes (e.g., config options). If none, state "NO."
• Impact - Hardware: Specifying "arm-v8m" and "arm-v7a" is good, but mentioning the specific boards and configurations used would be better. For example, "arm-v8m: stm32f429i-disco: default config"
• Impact - Documentation: It's unclear if documentation updates are needed or provided. Explicitly state "YES" or "NO" and provide details if "YES."
• Impact - Security: Even if there's no security impact, explicitly state "NO."
• Impact - Compatibility: While mentioning compatibility with board_crashdump, it should be clearer about how that compatibility is maintained (e.g., through a configuration option). Expand on "Should compatible with current running projects/defconfig" — does this mean no changes are required for existing users' configurations?
• Missing "Anything else to consider": Even if there's nothing else, explicitly state "None."
• Testing Logs: The template requests "before" and "after" logs, which are missing. While CI tests are mentioned, including snippets of relevant log output demonstrating the change's effect would be beneficial. If the logs are too extensive, consider providing a link to CI logs or a separate file.

Recommendation: Revise the PR description to address the weaknesses outlined above. Providing greater detail and explicitly addressing all points in the template will improve clarity and make the review process smoother.