Design and agree on tagging conflict resolution and fallback semantics

[teh-cmc]

Even after we land the new partial update APIs, we can still end up in situations where the data is untagged, multi-tagged, or both (same data logged as both untagged and tagged).
This will be very common with pre-existing data (think backwards compat).

We need to decide what the semantics should be used to resolve these conflicts.

One set of semantics that comes fairly naturally to mind is "most-specific at timestamp wins" (whether it's actually a good idea in practice, who knows).

I.e. with the code from earlier:

rr.set_time_sequence("frame", 42)
rr.log("points", rr.Points3D([[0, 0, 0], [1, 1, 1]], colors=[255, 0, 0]))

rr.set_time_sequence("frame", 42)
rr.log("points", [rr.components.ColorBatch([0, 0, 255])])

rr.set_time_sequence("frame", 43)
rr.log("points", [rr.components.ColorBatch([0, 255, 0])])

# There are three columns in the database now:
# * `points@Points3D:Position3D#positions`
# * `points@Points3D:Color#colors`
# * `points@Color`
#
# What colors should the visualizer use for frame #42? `points@Points3D:Color#colors`, because it is the most specific one available at this timestamp.
# What colors should the visualizer use for frame #43? `points@Color`, because it is the most specific one available at this timestamp.
# What colors should the visualizer use for frame #100? `points@Color`, because it is the most specific one available at the closest timestamp.

Upsides:

• Fixes the issue.
• Does not even require touching user code! Maybe even helps us maintain backwards compat for old untagged RRD files a bit longer?
• We will eventually need some set of new query semantics in any case, in order for tagged and untagged data to coexist in a peaceful and useful way.

Downsides:

• Getting these semantics right will likely not be an easy feat.
• Getting these semantics wrong can quickly turn into a rabbit hole of unforeseen issues and never-ending refactorings.