refactor(Alerts.Sort): more performant comparison

[thecristen]

Scope

While tackling #3310 I noticed that Alerts.Sort.sort/2 was featuring prominently in my flame charts, and I wanted to see if I could do anything about that.

Implementation

First of all. /stops/<mode> pages don't even show alerts. So the first commit moves the call which assigns alerts to conn to the specific method behind rendering the individual stop pages, instead of being invoked for every page handled by DotcomWeb.StopController.

Then when debugging Alerts.Sort.sort/2, I noticed the sorting logic included assessing the next active period start time. And I remembered we'd later implemented a different function for computing that, over at Dotcom.Alerts.StartTime.next_active_time/2! So I wanted to see if reusing that was more performant (and looks like it is!).

These charts were generated from loading South Station page with an already warmed cache.

Before (6.5MB)	After (3.3MB)

How to test

We could verify if the subway Planned Work section still sorts those alerts in the same way as before.

[lvachon1]

I only found one place where the sorting of alerts wasn't quite the same between prod and this branch. I don't think it's relevant though, the alerts seem to be for the same timeframe.