fix: Alert counts for multi-trip alerts in commuter rail status

[joshlarson]

Before

After

The fix is deceptively simple, and also a bit inelegant. We already have Dotcom.SystemStatus.CommuterRail.commuter_rail_route_status/1, which figures out the correct delay/cancellation count, so we can just use the data from that to populate commuter_rail_status/0 as well.

The inelegance comes from the fact that the <.alerts_commuter_rail_status /> frontend component relies on the data structure returned from commuter_rail_status/0 being structured a particular way, which is different from how commuter_rail_route_status/1 does it. So I added a bit of "adapter" logic to route_info/1 to convert the data structure commuter_rail_route_status/1 presents to the data structure `<.alerts_commuter_rail_status /> expects.

(This is especially inelegant because commuter_rail_route_status/1 already makes a distinction between train impacts (delays and cancellations) and service impacts (everything else), and <.alerts_commuter_rail_status /> does care about that distinction, but has to re-figure it out on its own, because commuter_rail_status/0 treats them all the same.)

Medium/longer-term, I think the thing to do is to update <.alerts_commuter_rail_status /> to accept commuter_rail_route_status/1-shaped data. I'm actively working on that now, and can add that to this PR. But this fixes a rider-facing bug, so I figured I'd share this commit as a standalone fix. We can decide whether we want to merge as-is and treat a more elegant approach as a follow-up, versus combining it all together and holding this PR until the refactor is done.

Asana Ticket: Fix how we count cancellations/delays on CR system status

[thecristen]

This seems pretty reasonable~

[thecristen]

I wonder if this should use Enum.into/3, like (untested)

|> Enum.into(%{
  cancellation: impact_summary(cancellations),
  delay: impact_summary(delays)
}, fn {effect, impact_list} ->
  {effect, impact_summary(impact_list)}
end)

[joshlarson]

Ooooh I almost wonder if it would be cleaner to swap the order of impact_summary, filtering, and adding in delays+cancellations to reduce more duplication... something like (also untested):

|> Enum.into(%{
  delay: delays,
  cancellation: cancellations,
})
|> Enum.reject(fn {_effect, impact_list} -> Enum.empty?(impact_list) end)
|> Map.new(fn {effect, impact_list} -> {effect, impact_summary(impact_list)} end)