[WIP] Adding Dual Stack lock example slcp with BLE on efr32

[sabollim-silabs]

Issue Link:
Few changes are needed in matter_sdk, which should be merged into CSA and pulled into matter_sdk main, before merging this PR.

Description of Problem/Feature:
Allegion Dual Stack architecture required the BLE on EFR32 and disbale 917 BLE.

Description of Fix/Solution:
Added new slcp and slcw for lock app example to implement Dual stack architecture.
Added changes to siw917_ncp to include EFR32 BLE files

Testing Done:
Build succesful and BLE commissioning validated

---

Note

Medium Risk
Primarily build/configuration changes, but they alter BLE platform selection and compilation inputs for SiWx917 NCP vs EFR32, which can cause runtime commissioning or link/build regressions if misconfigured.

Overview
Introduces a new lock-app-917-ncp-dual-stack application (.slcp) and workspace (.slcw) that packages the Matter WiFi lock example together with a bootloader and updated SDK extension versions.

Updates the siwx917_ncp component to make BLE integration conditional: SiWx917 BLE headers/sources and SLI_SI91X_ENABLE_BLE are excluded when matter_ble is enabled, and EFR32 BLEManagerImpl.cpp is used instead; also adds an additional BLE SDK include (rsi_common_apis.h) and refreshes component description text.

^{Written by Cursor Bugbot for commit c1dc723. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[cursor]

Missing from: directives for SDK extension components

Medium Severity

Every existing .slcp file in this project (e.g., lock-app-917-ncp.slcp, air-quality-sensor-app.slcp) consistently specifies from: matter for Matter extension components and from: wiseconnect3_sdk for WiSeConnect components. This new file omits all from: directives for dozens of components from both SDK extensions. This breaks the established convention and risks component resolution ambiguity.