Rename the island alter hook and the service IDs before RC1

Problem/Motivation

Child of #3624396: Plan: Harden InstanceInterface, IslandInterface and DisplayBuildableInterface as public API before RC1. Three names leave the module's namespace or its conventions, and get expensive once 1.0 ships:

• hook_island_info_alter(). Hooks share one namespace, and drupal.org has a project named island, whose hooks are hook_island_*.
• plugin.manager.db_island, the one service ID with an abbreviation, where "db" reads as database.
• The other service IDs are strings, display_builder.* and their submodule equivalents. Core gives services their class name as ID, and keeps string IDs for plugin managers only.
• The 11 builder events are named onUpdate, onAttachToRoot and so on: event names are global, and core prefixes them with the module. Their docblocks also promise more than happens: "Fired when a new node is attached directly at root level", while they fire only from the builder UI, never for a change made through InstanceInterface.

Proposed resolution

• hook_island_info_alter() becomes hook_display_builder_island_info_alter().
• plugin.manager.db_island becomes plugin.manager.display_builder_island. plugin.manager.display_buildable stays: it already follows the convention, and the instance's buildable field stores it.
• Every other service of the module and its submodules takes its class name as ID. The existing class name aliases become the IDs.
• The discovery cache key island_plugins becomes display_builder_island_plugins.
• No deprecated alias. The known users, UI Controls and display_builder_ai, change and release at the same time, and require the release that renames.
• Document the renamed hook in display_builder.api.php, as #3627266: Mark the API boundary: @api on what contrib extends, @internal on the rest plans for both alter hooks.
• The values of the 11 DisplayBuilderEvents constants take the module prefix: display_builder.update, display_builder.attach_to_root, display_builder.attach_to_slot, display_builder.move, display_builder.active, display_builder.delete, display_builder.history_change, display_builder.restore, display_builder.revert, display_builder.publish, display_builder.preset_save. The constant names stay, so a subscriber using them is unaffected. No code relies on the values: the island fan-out maps each constant to a method of its own.
• Their docblocks say what they are: builder UI events, fired by the builder after an action, carrying the islands' updates back to the browser. One line on the class: a change made through InstanceInterface outside the builder fires none of them.

Remaining tasks

• Update UI Controls: IslandInfoHooks and StylesIslandTest.
• Update display_builder_ai: AddComponent and SetLayout.
• Write the change record.

User interface changes

None.

API changes

• hook_island_info_alter() renamed hook_display_builder_island_info_alter().
• plugin.manager.db_island renamed plugin.manager.display_builder_island.
• Service IDs display_builder.*, display_builder_entity_view.*, display_builder_page_layout.* and display_builder_views.* replaced by class names.
• DisplayBuilderEvents values prefixed with display_builder., constant names unchanged.

Data model changes

None. The island discovery cache rebuilds under its new key.