Update book submodule to enable automated creation of metadata fields and mapping

Problem/Motivation

Currently, the expectation is that users generated the book metadata fields and then map them to the appropriate endpoints in the ePub via the settings form. Let's give the option to have the site take these actions.

Proposed resolution

Add a BookMetadataFieldInstaller service holding the canonical definition of every metadata field, and expose it as a one-click action on the field mapping form plus a Drush command.

The definitions are the single source of truth and match what BookEpubAssembler's extraction expects: author is unlimited cardinality (all items are read), the layout/spread/orientation lists carry exactly the values the assembler passes through to the package document, and the viewport fields are integers. description is deliberately excluded — it maps to the standard body field, which node types already have (though we may update this for Drupal 12).

install() is idempotent: existing storages and instances are reported and left untouched, fields whose type module (image, options) is disabled are skipped with a warning, and a pre-existing storage of a mismatched type is treated as a conflict rather than reused.

The canonical field names match the existing config/install mapping defaults, so sites that never use the action see no behavior change.

Remaining tasks

• Review.
• Run the unit tests for the field definitions.
• Add kernel test coverage for install() — field creation, form display placement, and idempotency on re-run are not reachable from unit tests.
• Kernel test coverage for the form itself, which now depends on BookHelperTrait and therefore needs Book installed. Two Book 3.x incompatibilities reached testing precisely because no test installs Book: reading book.settings:allowed_types as a flat list of type IDs (it is a sequence of {content_type, child_type} mappings) and reading $node->book as a plain property (Book 3.x uses a bundle class with a protected property behind getBook()).
• Decide whether the assembler should honor Book 3.x's per-content-type child_type, which it currently ignores. Not a bug today; relevant if the recipe scaffolds an outline.

User interface changes

• ePub Book Field Mapping gains a "Set up metadata fields" section: a content type select (marking types allowed in Book outlines, defaulting to the first) and a "Create and map metadata fields" button.
• The action reports its outcome via the messenger, grouped into created, already present, skipped (field type module disabled), and conflicting (existing field of a different type).
• New Drush command epub:setup-book-fields <bundle> (alias epub-sbf) for scripted or demo-site builds.

API changes

New service epub_generator_book.field_installer (BookMetadataFieldInstaller) with a public static getFieldDefinitions(), plus install(string $bundle) and applyMapping(). BookFieldMappingForm gains a constructor and create(); it previously used the base class defaults, so any subclass overriding the constructor needs updating.

Data model changes

None to the module's own schema. The action creates optional field storages and instances on a site-chosen content type — field_book_author, field_subtitle, field_isbn, field_book_publisher, field_copyright, field_edition, field_cover_image, field_epub_layout, field_viewport_width, field_viewport_height, field_epub_spread, field_epub_orientation — and writes field_mapping in the existing epub_generator_book.settings. Nothing is created on install or uninstall; the action is opt-in and additive.