Regenerate the lock file when the installer removes front-end tool dependencies

[AlexSkrypnyk]

Summary

When the installer removes a front-end tool, it edits package.json but leaves package-lock.json untouched. The two then disagree, and npm ci refuses to install: it treats the lock file as authoritative and aborts rather than reconciling it.

This affects a generated project on its first build, so it surfaces as a broken site rather than as a warning.

Details

The gap is partial deselection. When every front-end tool is deselected, the frontend_all group removes package.json and package-lock.json together, so that path is consistent. When only some are deselected - ESLint off with Jest kept, for example - package.json is rewritten through JsonManipulator::updateFile(), the lock file is left as it was, and the pair no longer matches.

The behaviour is not specific to ESLint. Every tool in the map edits package.json the same way, so any combination that removes one tool and keeps another reaches it. It also predates the move to npm: yarn.lock was committed before that change and yarn install --frozen-lockfile fails on the same mismatch, so only the error message changed.

• Keep package.json and its lock file consistent whenever the installer removes tool dependencies, for every tool in the map rather than for one of them.
• Cover partial deselection, where one tool is removed and another is kept, since full deselection already removes both files together.
• Apply the same treatment to the custom theme, which carries its own manifest and lock file.
• Add installer coverage for a partial deselection, asserting the resulting manifest and lock file install cleanly.

Found during review of #3047: #3047 (comment)