Image component's image style list is hardcoded; load the configured image styles

Problem/Motivation

LBKImage::blockForm() hardcodes the image style select options (4.0.x line 162, 3.0.x line 161):

'#options' => [
  'none' => 'none',
  'thumbnail' => 'thumbnail',
  'medium' => 'medium',
  'large' => 'large',
],

Two consequences:

• Custom image styles are unreachable. A site that defines its own styles - the normal case on any real build - cannot select them in the Image component, even though the render path already goes through the image_style theme hook and would happily use them.
• A deleted core style leaves a dangling reference. Nothing validates that the four hardcoded names still exist. If a site deletes the medium style, the option is still offered and the stored #style_name is still passed to the image_style theme hook, pointing at a style that is no longer there.

Proposed resolution

Build the options from the image_style configuration entities instead of a literal array, keyed by the style machine name with the style label as the option text, plus the existing none entry.

The change is additive and safe. The four hardcoded names - thumbnail, medium, large - are core defaults shipped by the Image module, so they will normally still be present in the generated list and existing stored block configuration keeps resolving exactly as before. Sites that have deleted one of them are already broken today; loading the real list is what surfaces that.

Use the injected entity type manager. LBKImage already injects its services through create(), and calling \Drupal::entityTypeManager() in a plugin that has dependency injection available is flagged by DrupalPractice.

Steps to reproduce

1. Create a custom image style at /admin/config/media/image-styles.
2. Add an Image component to a layout and open its settings form.
3. The image style select offers only none, thumbnail, medium and large. The custom style is not listed.

Remaining tasks

This was split out of #3318209, where a patch by ecj implements it. Credit to ecj for spotting and fixing this. The patch is a good starting point but it should not be applied as-is - it contains three problems an implementer should avoid repeating:

1. It calls \Drupal::entityTypeManager() statically. This module injects its services; use the injected manager instead.
2. It uses $style->get('name') for the option key. The correct accessor for a config entity's machine name is $style->id().
3. It calls $this->t($styles->get('label')). Passing a variable to t() is a coding-standards violation - translatable strings must be literal so the string extractor can find them. The label of a user-created config entity is already a site-authored string and should be output directly, not wrapped in t().

• Implement the option list from the injected entity type manager, avoiding the three issues above.
• Decide how to handle a stored #style_name that no longer resolves to an existing style - fall back to none rather than rendering a broken image style.
• Add test coverage asserting that a custom image style appears in the settings form options.