chore: the this-pointer naming rule and the concrete writer classes disagree

[DavidCozens]

Raised from a review comment on #730, declined there because it is a tree-wide
question rather than one parameter.

docs/NAMING.md states the Tier 3 this-pointer rule as:

base when the declared type is the abstract base struct, self otherwise.

Three concrete writer classes name it descriptively instead:

Function	First parameter
SolidSyslogSdElement_Begin / _Param / _End	element
SolidSyslogSdValue_String / _Uint32 / …	value
SolidSyslogHeaderField_PrintUsAscii / _Uint32	field

They are consistent with each other and inconsistent with the stated rule, so
this is not drift in one place — it is a rule written with vtable-dispatched
roles in mind, applied to a family that has no base struct to distinguish from.

The decision

Two coherent outcomes, and either is fine as long as it is chosen:

• Rename the family to self, making the rule literal everywhere. Touches
  three headers and their sources, mechanical, no behaviour change.
• Narrow the rule to say self is required where a class has an abstract
  base to be distinguished from, and a descriptive name is acceptable for a
  concrete writer that never dispatches. NAMING.md already reserves both self
  and base tree-wide, so nothing else is at risk from allowing a third name.

Worth noting the second is not merely the cheaper option: element, value and
field read better at their call sites than three identical selfs would, in
code whose whole job is that the author can see what they are writing into.

Not urgent, and not a defect — but a stated rule that the code does not follow is
the shape that let the platform naming drift far enough to need a rename, so it
should not just sit.

[DavidCozens]

Milestoned to 0.2.0, and the recommendation is narrow-the-rule

Reviewed against the tree during the pre-0.1.0 issue audit. Nothing has drifted:
docs/NAMING.md:378-391 still states the rule as chosen by the declared
parameter type, not by the function's purpose, and all three families still take
element, value and field while declaring their own concrete class.

The two outcomes are not equally good, and the second is not the cheap one.

The rule's basis is disambiguation. self against base tells a reader which
view of a two-view object they are holding — the concrete class, or the abstract
base whose vtable dispatched to them. SolidSyslogSdElement,
SolidSyslogSdValue and SolidSyslogHeaderField have exactly one view each. No
vtable, no base struct, nothing to be distinguished from. So self carries no
information at these call sites; it only costs the reader the word that said what
was being written into.

This is not a family that broke the rule. It is a rule written for
vtable-dispatched roles, applied where its premise is absent. Narrow it.

The narrowing, and its closing condition

self is required where the class has an abstract base to be distinguished from.
A descriptive name is permitted for a concrete writer that never dispatches.

State the boundary explicitly, or the next family invents a fourth convention:
the class has no vtable and no base view, and the descriptive name is the noun
the class is — element for SolidSyslogSdElement, not an abbreviation and
not a role word.

docs/NAMING.md:464 already reserves self and base tree-wide at Tier 3, so
permitting a third name here puts nothing else at risk.

No code change. This is a docs/NAMING.md edit.

Do this with #682

Same file, same shape — a stated rule the code does not follow — and now the same
milestone. #682 carries the "Tier" terminology decision and the (public API)
parenthetical on the Tier 1 heading. Both are one sitting with docs/NAMING.md,
and doing them separately means reading the same document twice.