Kleaf: enable menuconfig with multiple fragments by merging changes to the last file

Previously, when `pre_defconfig_fragment_files` contained more than one file,
the `kernel_config` rule would fail during `menuconfig` execution, forcing
users to manually update configuration files. This hindered development
workflows involving complex, multi-fragment configurations.

This change updates the `_get_config_script_impl` function to automate the
merge process for multiple fragments:

1. **Dynamic Baseline Construction**: At runtime, the script generates a
   temporary baseline config (`accumulated_config`) by merging the `defconfig`
   with all fragment files *except* the last one.
2. **Diff Calculation**: After the user completes modifications via
   `menuconfig`, the script uses `scripts/diffconfig` to compare the baseline
   (`accumulated_config`) against the final modified config (`.config`).
   - The resulting diff fragment naturally includes both the original content
     of the last fragment and the new user changes.
3. **Automatic Merge**: The calculated diff is sorted and written back into
   the **last** file in `pre_defconfig_fragment_files`.

Additionally, this fix addresses a Python string formatting error:
- Correctly escapes Shell variables (changing `${var}` to `${{var}}`) to
  prevent `Error in format: Missing argument`.
- Updates the `trap` cleanup logic to ensure newly created temporary files
  (`accumulated_config`, `frag_tmp`) are removed upon script exit.

**Note on `len == 1` vs `len > 1` branching:**

The `len == 1` and `len > 1` cases cannot be unified into a single code path
because they use fundamentally different strategies to determine the correct
fragment content:

- **`len == 1`**: The `new_fragment` variable (produced by merging the single
  fragment with `changed_config`) already contains exactly the correct content
  for the fragment. We write it directly via `sort_config ${new_fragment}`.

- **`len > 1`**: The `new_fragment` variable contains ALL fragments merged
  together plus user changes. Writing it to the last fragment would incorrectly
  include settings from all earlier fragments. Instead, we must build an
  `accumulated_config` (defconfig + non-last fragments) and use `diffconfig`
  to extract only the last fragment's contribution.

Additionally, the `len > 1` case supports a non-menuconfig mode that checks
whether the fragment is in sync with the generated config and emits a WARNING
if it diverges, rather than overwriting the file.

These two approaches are architecturally distinct and cannot be merged without
introducing unnecessary complexity or correctness issues.

Test:
- Verified that `config.sh` generates successfully for both single and
  multi-fragment configurations.
- Confirmed that `menuconfig` changes are correctly applied only to the last
  fragment file, leaving preceding fragments unchanged.
- Validated that temporary files are properly cleaned up after execution.
- Verified that non-menuconfig runs preserve fragment files and emit a
  WARNING when out of sync.

Bug: 468968638
Change-Id: Iab274829233e6744a87b69d583771980f7529299
Signed-off-by: Cixi Geng <cixi.geng1@unisoc.com>
(cherry picked from commit 71d70c1292c90673b0e53dbb385c4b0cc59e10d1)