tp: hand machine-wide data over when its owner's data ends

Builds on the whole-trace claims: scheduling and each machine counter
track are still owned by the first trace whose write is kept, but only
until that trace's data for them ends. After that, the next trace to
write takes over. This keeps a later trace's data after an earlier one
ends (partial overlap, back-to-back series) while still dropping the
duplicate copy where traces overlap.

- Lease: while tokenizing, each trace records the last timestamp of the
  streams that can write each destination: sched events for scheduling;
  ftrace, sys_stats, battery, entity state, generic kernel, systrace
  and dumpstate, depending on the counter type. Archives are fully
  sorted, so all files are tokenized before the first parse-time
  decision. Until then, or for traces with no recorded bounds, the lease
  never ends.
- Handover: a write from another trace after the owner's lease makes it
  the owner. The old owner's open sched slices and thread states are
  closed at its lease end through its own FtraceSchedEventTracker and
  ThreadStateTracker, without table scans. A trace whose sched slices
  can't be closed this way (generic kernel or ETW only) keeps
  scheduling until the end, as in the whole-trace claim. Counter tracks
  are handed over the same way: the next trace to write takes over.
- Wakeups, new-task runnable states and blocked reasons never claim and
  are dropped while another trace owns scheduling. Before anyone owns
  it, they are dropped when an earlier-starting trace's sched events
  cover them. Each dropped kind is logged once per trace in the import
  logs.

Limitations are listed in the class comment and the docs: equal start
timestamps follow the sorter's order; a destination keeps blocking
until all streams that can write it end; each CPU or thread is empty
after a handover until the new owner's next event; generic-kernel-only,
ETW and JSON traces never hand over scheduling; Fuchsia sched writes
are not checked.