[#601] BIRTH messages convey both 'now' and 'last change' timestamps

[wes-johnson]

[#601] BIRTH messages convey both 'now' and 'last change' timestamps

Closes #601. Per the spec team decision on the issue. Chapter 6 only, no schema field renamed.

Two normative statements, both [tck-not-testable]:

• In a BIRTH or REBIRTH, the payload timestamp represents publish time and all Metric values MUST be
  current as of it.
• In a BIRTH, REBIRTH, or DATA message, a Metric's timestamp MUST represent the metric value change
  time — the time that value last changed — and MUST NOT represent read time or publish time.

The second is the behavioural change. Chapter 6 previously called this field "data acquisition time",
which invited an Edge Node to stamp every BIRTH metric with the read time — for a BIRTH, publish time —
collapsing the two times into one. Chapter 4 already said "metric value change time" in six places;
the three Chapter 6 references now match it.

Both are tck-not-testable because the requirement constrains what the number means: a metric
timestamp equal to the payload timestamp may be a genuine change or a substituted publish time, and
nothing on the wire separates them. Consistent with the timestamps-resolution-scaling demotion in
#624. 0 tck-ids added.

Unchanged: the field name timestamp = 3, the omitted-timestamp default (still falls back to the
payload timestamp), and the NCMD/DCMD write-time statements.

Also adds a non-normative note that the distinction between a reported and a substituted change time
is carried by field presence, not by value — a consumer needing to know whether an Edge Node reports
change times at all checks presence rather than comparing against the payload timestamp.