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).