Slot handlers as island plugins

Problem/Motivation

Some current and planned tasks may be related:

• BuilderPanel is too complex (see #3559572: Evaluate and refactor buildSingleBlock), and TreePanel & LayersPanel are too tightly coupled to BuildePanel. So maybe some logic must be moved elsehwere.
• Some proposals for slot management (for example: #3569389: Improve UX for adding content to empty slots and #3538730: UI parent selection. Maybe some parts of #3544026: Cardinality & suggested components constraints for slots and #3551232: Add a lock system) will be better implemented by a dedicated island plugin

Proposed resolution

1. Pass a full InstanceInterface between BuildePanel

Instead of string $instance_id as we already did in #3578999: Pass existing Instance object to islands methods instead of loading it again. This is necessary to be bale to send the current state (so, the instance entity) to the new island plugin.

This will also help consolidating the logic, because InstanceInterface is more specific than string. Also, this will remove the last remaining ambiguity between instance/node/builder terminology (following #3538360: Profile & Instance naming normalization.

We may extract this work to a dedicated ticket if it makes review simpler.

2. Slot handlers as island plugins

2 steps:

1. Add a new slot handler island typeIn IslandType, in ProfileForm...
2. Move BuilderPanel::buildComponentSlot() logic to its own island

#[Island(
  id: 'dropzone',
  enabled_by_default: TRUE,
  label: new TranslatableMarkup('Dropzone'),
  description: new TranslatableMarkup('...'),
  type: IslandType::Slot,
)]
class Dropzone extends IslandPluginBase {

Do we also introduce a mechanism which force at least one island to be activated for a specific type?