server: Add typed entity components

[cqdetdev]

Summary

Adds an open, typed component system to entities. This is the first of
three planned PRs modernising the entity API and is fully additive:
no existing API changes, no behavioural changes for existing entities,
and byte-identical network output for all built-in entity types. The
existing Behaviour model is untouched and continues to work.

Problem

Entity state and logic currently live in a single opaque value
(EntityData.Data any) holding one Behaviour. In practice this closes
the entity system to external packages:

• Custom state cannot be attached to an entity you didn't define.
• Custom state can never render client-side: the session builds actor
  metadata from a fixed set of type assertions on known behaviours.
• Custom state cannot persist: entity NBT is split between the handle
  and the EntityType.
• Blocks and items can only ever spawn the entity types hardcoded in
  EntityRegistryConfig's closures.

What this adds

Typed components on entities, accessed through keys created at
registration:

var Charged = world.RegisterComponent[ChargedData]("myplugin:charged")

type ChargedData struct{ Level int }

// On any entity — a vanilla arrow, another package's entity, a player:
Charged.Attach(e, ChargedData{Level: 3})
if c := Charged.Of(e); c != nil { // pointer for in-place mutation
    c.Level++
    world.MarkMetaDirty(e) // resend metadata after mutating a syncer
}
Charged.Detach(e)

Components may implement optional capabilities:

• TickerComponent — per-tick logic, run before the entity's
  behaviour. Ticker lists are cached per entity, so components may
  attach/detach components (including themselves) during their tick.
• MetaSyncer — contributes client-visible metadata through typed
  setters (SetScoreTag, SetVariant, SetScale, SetColour and SetFlag).
  Runs after built-in metadata; Attach/Detach
  resend automatically.
• NBTSaver — persists with the entity under a Components compound
  in chunk NBT. Data saved under component names not registered in the
  running process round-trips losslessly to the next save.

Declarative entity types replacing hand-written EntityType
boilerplate, validated eagerly at registration (unregistered component
types, duplicates and multiple behaviours panic at init, not at first
spawn):

var AcidBall = entity.RegisterType(entity.Spec{
    Name:      "myplugin:acid_ball",
    NetworkID: "minecraft:snowball", // rendered client-side as a snowball
    Box:       cube.Box(-0.125, 0, -0.125, 0.125, 0.25, 0.125),
    Components: func() []any {
        return []any{
            entity.ProjectileBehaviourConfig{Gravity: 0.05, Drag: 0.01}.New(),
            AcidTint{}, // MetaSyncer: green potion swirl, previously impossible
        }
    },
})

A Behaviour among a Spec's components becomes the entity's main
behaviour, so spec-based types get full existing physics today.

Open spawning — any registered spec type can be spawned by name
from block, item or user code, without touching EntityRegistryConfig:

ent, ok := tx.SpawnEntity("myplugin:acid_ball", opts, Owned{Owner: p.H()})

Dependency

This PR pins HashimTheArab/gophertunnel#89, which adds the typed protocol metadata keys used here. The dependency PR is based on the exact gophertunnel revision Dragonfly already used, so the replacement adds no unrelated fork changes.

[RestartFU]

can you like stop giving up on your PRs 🙏🏻