extract-protocol.py drops the field name for single-value packets, so they generate as tuple structs

[andrewgazelka]

extract-protocol.py records a single-value packet's layout as the bare wire
kind and drops the field name, so the generator has nothing to name the field
after and emits a tuple struct.

ClientboundTickingStepPacket becomes, in protocol.json:

"net.minecraft.network.protocol.game.ClientboundTickingStepPacket#STREAM_CODEC": {"kind": "varint"}

and in the generated Rust:

pub struct TickingStep(#[proto(varint)] pub i32);

Mojang has a name for that value. The packet's own field is tickSteps, and
TickingStep { steps: i32 } reads better at a call site than TickingStep(3).

The name is missing because these packets do not go through
StreamCodec.composite -- their codec is ByteBufCodecs.VAR_INT mapped
straight onto the constructor -- so the extractor never sees a field label to
record. It would have to read the class's own single field, or the
Function/getter argument of the StreamCodec.map call.

This affects about 30 packets: TickingStep, LoginCompression,
BlockChangedAck, SetCamera, AcceptTeleportation, KeepAlive,
ContainerClose and the rest of the one-value set.

Deliberately not done in #974, which is where this surfaced: the alternative
was inventing a field name in build.rs, and a made-up name in a generated
API is worse than a positional one. nix/ was also owned by a branch in
flight at the time.

Suggested fix: have the extractor emit {"kind": "struct", "fields": [{"name": "tickSteps", "wire": {"kind": "varint"}}]} for a codec it can attribute to a
single named field, and leave the bare form for the ones it cannot. The
generator already produces a named struct from that shape with no change.