Issue #3614068: Read the image settings the module actually ships

Fixes the orphaned image configuration described in the issue.

What was wrong

Four places disagreed, not the two named in the issue:

	Config object	image_location	image_extensions
config/install	…settings	flat	flat
Settings form	…image_component	nested	nested
LBKImage	…image_component	nested	nested
LBKIconText	…image_component	flat	nested

LBKIconText was not mentioned in the issue and is the worst case: it read a flat image_location from the nested object, so its upload folder was ignored even after an administrator saved the form. It never worked under any configuration.

Fix

Everything now uses layout_builder_kit.settings with flat keys — the object and shape that config/install already ships.

layout_builder_kit_update_10001() copies any values an administrator saved into the old object before deleting it. It skips empty values so a partially populated object cannot blank out a working default, and no-ops when the object was never created — so it is safe to re-run, and safe for sites upgrading 3.0.x → 4.0.x. The 4.0.x rewrite had removed the .install file, so it is reintroduced.

The schema entry for the superseded object is kept, marked deprecated. Sites still hold that object between deploying this code and running database updates, and schema has to outlive the data it describes. It also lets the migration be tested. Safe to drop a release later.

Tests

SettingsFormTest asserted the old broken key shape, so it was encoding the bug — it now asserts the shipped configuration is what the form reads and writes, and that the installed defaults are readable without saving the form.

ImageUploadConfigTest (new) covers both components for the actual defect: extension lists must be non-NULL, and configured values must be honoured.

ImageConfigUpdateTest (new) covers the migration, its idempotency, and empty-value protection.

Local verification on Drupal 12.0-dev / PHP 8.5: 29 tests, 104 assertions, all passing (up from 27/92). phpcs clean, cspell clean, phpstan shows no new findings.

End-to-end on the running site, which is the load-bearing check — before the fix both were NULL:

lbk_image      upload_location: public://layout_builder_kit  extensions: ["gif png jpg jpeg webp"]
lbk_icon_text  upload_location: public://layout_builder_kit  extensions: ["gif png jpg jpeg webp"]

Still to do: port to 3.0.x, which has the same four defects but must keep working on Drupal 10.

Closes #3614068