defconfig: Delete the redundant Kasan configuration on CI

[W-M-R]

Note: Please adhere to Contributing Guidelines.

Summary

arm/qemu-v7a:
            1. Keep arm/smp configuration, use kasan in generic mode
arm64/qemu-v8a:
            1. Keep arm/citest configuration, use kasan in generic mode
            2. Keep arm/swtags configuration, use kasan in software tag mode
sim:
            1. Keep sim/ostest, use asan
            2. Keep sim/ostest_oneholder, use kasan in generic mode

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

This PR appears incomplete and does not fully meet the NuttX requirements. The summary is too brief and lacks crucial information. It mentions changes related to KASAN and ASAN but doesn't explain why these changes are necessary or how they work. There's no mention of a related issue. The impact and testing sections are completely empty.

Specifically:

• Summary: Needs to explain the motivation for these changes (bug fix, performance improvement, new feature?). What was the problem before and how does this change address it? How does KASAN in "generic mode" differ from other modes? What is the purpose of these specific configurations for each architecture?
• Impact: All impact sections need to be filled out, even if the answer is "NO". If there is an impact, a description is required. For example, even if user impact is NO, explicitly state "Impact on user: NO". The use of sanitizers like KASAN and ASAN could have impacts on performance, memory usage, and build time. These need to be addressed.
• Testing: The testing section must be completed. Provide details about the build host (OS, compiler version etc.) and target platforms. "Before" and "after" logs are required to demonstrate the effect of the change. Without these logs, there's no evidence the changes work as intended. How was the functionality verified?

Therefore, this PR needs significant revision before it can be considered.