Add deaths_log with gold lost and time dead per death

[geracosta]

Implements the deaths_log half of odota/core#1465: a per-player log of deaths with {time, key, gold_lost, time_dead}, where key is the killing unit (hero, tower, creep — or the player's own hero for suicides). Also covers odota/core#2294 and odota/core#1780, which ask for the same log.

• gold_lost comes from the combat log gold entries with the hero-death reason. It matches gold_reasons["1"] exactly per player on the reference replay; on current patches it's 0 since the game removed death gold loss, but historical replays populate it.
• time_dead comes from life_state transitions in the interval entries (death to respawn, so buybacks shorten it). If the match ends before the respawn, the field is absent rather than guessing. Per player it sums to the dead seconds in the existing life_state map.
• Deaths follow the same filters as killed_by (real heroes, no illusions, aegis deaths excluded) except self-kills, which are real deaths (they count on the scoreboard and lose gold) even though no kill is credited — e.g. Techies suicides.
• The gold and life_state data are collected in a pre-scan keyed by event time because the combat log death entry, its gold entry and the interval entries around it are not strictly ordered in the stream.

Verified on two replays (the 1781962623 test file and a current-patch match) against the blob's own aggregates and the scoreboard: deaths_log length equals scoreboard deaths for all 20 players (including a Techies game: 10 deaths = 7 kills by enemies + 3 suicides), gold_lost sums equal gold_reasons["1"] for all players, and the rest of the blob is byte-identical to master's output.

On the assists_log half of #1465: CDOTAUserMsg_ChatEvent does carry the assisters in playerid_3..6 for hero kill events, but Parse.java currently only reads playerid_1/2 — so it's feasible as a follow-up and I kept it out of this PR to keep the diff small.

Companion core PR: odota/core#2973.

[howardchung]

Same question around the need to precompute/reorder. I don't think we are doing this for kills_log, so even if it's confusing in some ways it might be better to be consistent?

[geracosta]

It is consistent with kills_log where the two are comparable: the death entry itself ({time, key}) is emitted inline at the death event, same append-in-stream-order pattern as kills_log — no reordering there. The pre-scan only exists to fill the two extra fields, which can't be known at that point in the stream: time_dead is decided by the revive, seconds to minutes later, and gold_lost lives in a separate GOLD combat log record that isn't reliably ordered against the death record (it can land a second or two off by timestamp). kills_log never needs a join like that, so it never needed the maps.

If you'd rather not carry the lookaside maps, dropping gold_lost/time_dead would make this literally kills_log for deaths — but those two fields are the point of #1465 (measuring what the death cost).

[howardchung]

Hmm, my original comment of reading kills_log still applies here, it would be nice to avoid having to store what is essentially duplicate data.

This does add the gold_lost and time_dead information I guess, but are we planning any specific functionality with it?

[geracosta]

The use I had in mind is the death breakdown from #1465: per-death time, killed by, gold lost and time dead, like the Dotabuff death summary the requester posted screenshots of. Back then the answer was to open a parser PR to extract the data, which is what this PR is. To show where it lands I built the web side too: odota/web#3368 adds a Deaths table to the Combat tab, screenshot below (the tooltip is the same illusion kill #90 fixed, now with its gold and respawn cost). On reading deaths from kills_log: suicides are filtered out of it on purpose, deaths to towers/neutrals/Rosh aren't in anyone's kills_log, and gold_lost/time_dead can't be derived from it at all. The only real overlap is the {time, key} pair.

Also rebased onto master to clear the conflicts from yesterday's merges. No behavior change: deaths_log on the test replay is byte-identical pre/post rebase.