add alert message variants

[panentheos]

Summary of changes

This is a small refactor in advance of a larger one. Adds two new message variants:

• A short version of the single-line destination-specific "no service" message, which can fit on the top line.
• A destination-specific version of the full-page "no service" message.
  Note that neither of these messages are used yet, but they will be in a followup PR. The language has been ok'd by product.

Also reworks the line field in the "service ended" message as variant, to make it more general.

[digitalcora]

Just a note that I have looked at this but I'm not confident in my approval without test changes showing the difference in behavior — but then maybe those couldn't be included in this PR if no code actually uses the new messages yet. Maybe it makes sense to do the refactor and then the "real" task in the same PR, as separate commits?

[panentheos]

Yeah, this code is exercised by the extensive suit in realtime_test.exs, and the lack of diffs is what shows that this isn't used yet. I split out this and the other pieces to try to avoid putting up a very large PR, since they tend to be more burdensome to review, even if they're broken up in to logical chunks. The next PR will have some straightforward diffs in the test assertions that showcase the new messages.

[digitalcora]

One approach we could take is to base the following PR on this branch. Then they are separate PRs, but the first one doesn't have to be merged before the second one can be reviewed. GitHub will even auto-retarget the second PR to main when the first one is merged. But again, this would mostly be to benefit my understanding.

@PaulJKim Would you mind taking a look here? I'm not as familiar with these internals as you two.

[panentheos]

Ok, I pushed #828 as a draft, so you can refer to it while reviewing this. I'll rebase that and write a full description once this one goes in.

[PaulJKim]

The 'line' pattern is also used in custom.ex. Should we go ahead and refactor that while we're at it?

[panentheos]

That one's a bit different because we can't programmatically shorten or rearrange custom messages, like we can with these variants.

[PaulJKim]

I took a look at this as well and I think it would be fine to merge since the destination-specific messages are never actually used, as mentioned in the description. The change to the last trip stuff looks fine as well and just had a non-blocking comment related to that. I'll leave final approval to you @digitalcora since you initially reviewed it

[digitalcora]

Ha, my intention was to leave the approval to you as the resident expert... so I shall approve based on your approval 😄