[test] Add npu-xrt local_reset on-board tests (core/dma)

[jskimko]

Description

Adds a test/npu-xrt/local_reset/ suite of on-board tests for local reset -- returning a single tile-local block to a clean state from the runtime sequence, without rebuilding the design or reloading the array. Each family resets one block and checks that a resident design survives it.

Direct register-write families issue the reset from aie.runtime_sequence, using the same register-write type the aie-rt driver uses:

• core -- Core_Control (0x32000): masked reset -> unreset -> enable (XAie_CoreReset / XAie_CoreUnreset / XAie_CoreEnable) re-runs a halted core.
• dma -- DMA_MM2S_0_Ctrl (0x1DE10): masked reset pulse (XAie_DmaChannelReset), re-push BD, re-arm lock. Updated: the MM2S channel now holds a "bad" BD queued ahead of a "good" BD (both gated on a lock); the reset flushes the queue so only the good BD runs once the lock is armed.
• switch -- Stream_Switch_Slave_DMA_0_Config (0x3F104): tear down the slave port at each dispatch end and re-enable it at the start of the next, re-arm lock (XAie_StrmConnCctEnable / XAie_StrmConnCctDisable; slave port only -- the master route is resident, noted in the README). Removed: the stream switch is not a hardware reset domain (aie-rt has no stream-switch reset routine), so this was runtime connection reconfiguration rather than a reset.

Op-based families drive the merged runtime-sequence ops instead of writing the registers directly -- the on-board counterparts of core and dma, adding on-silicon coverage for ops that otherwise have only aie-opt FileCheck tests:

• core_reset_op -- aiex.core_reset ([AIEX] Add aiex.core_reset runtime-sequence op #3375). The op is reset-only, so for a core halted at aie.end the test composes it with a masked re-enable, giving the full XAie_CoreReset -> XAie_CoreUnreset -> XAie_CoreEnable driver sequence.
• dma_channel_reset_op -- aiex.dma_channel_reset ([AIEX] Add aiex.dma_channel_reset runtime-sequence op #3370), then re-push BD + re-arm lock.

Each family drives its protocol across repeated dispatches and self-checks the host-visible result; the op-based families reuse their raw sibling's test.cpp directly. All run on npu1 and npu2 (REQUIRES: ryzen_ai); every register offset is identical on both. Every offset, register-write type, and reset protocol is cross-referenced in the READMEs to the vendored aie-rt driver (third_party/aie-rt/).

Checklist

• Tests pass locally, or the change is covered by CI
• Docs / docstrings updated if the change is user-facing
• Code is formatted (clang-format for C++, black for Python -- see CONTRIBUTING)

[jskimko]

I'll wait on #3375 to be merged, then add tests using the new API for both core and dma.

[hunhoffe]

#3375 in merge queue :)

[andrej]

Looks good, my comments are mostly nitpicks, but should be easy to address if you could.

Follow-ups:

• Getting native MLIR operations for those raw-register writes would be useful. This helps with portability for future architectures, as well as understandability and debuggability. Lowerings for these additional ops could probably be tacked onto @atassis' existing core reset lowering pass.
• For the switchbox and DMA channel reset, I think it would be especially interesting if it is possible to change the switchbox or DMA channel after the reset. It looks to me that these tests currently re-run the same configuration after resetting and unresetting as before. I'd love to see this working for a reconfiguration, e.g. reset the switchbox and route it somewhere else between iterations of the test.

[jskimko]

• Replaced the dma test to avoid flaky sync issues by observing a queue reset instead.
• Dropped the switch test since this turned out to be more of a reconfiguration test rather than a true reset.

[andrej]

Discussed with Jason: the deleted reconfiguration tests might be added in a future PR.