chore: refactor function application over source_config values

[sloanelybutsurely]

Summary of changes

Defines map_source_config/2, a function for applying a function to SourceConfig values (both single and top/bottom--tuple).

Uses the new map_source_config/2 function to calculate alert_status, first_scheduled_departures, and service_end_statuses_per_source.

Reviewer Checklist

• Any new or changed functions have typespecs
• Tests were added for any new functionality (don't just rely on Codecov)
• This branch was deployed to the staging environment and is currently running with no unexpected increase in warnings, and no errors or crashes (compare on Splunk: staging vs. prod)

[digitalcora]

Since these are both only used in one module, and simplify in particular only has a single use, extracting them into public functions on SourceConfig feels a bit premature — unless this intentionally doesn't refactor all the places this could be used? (you mentioned "throughout the application")

The improvement in readability for the calling code is nice, though. Maybe these could be private functions?

Edit: I'm just noticing this is a Draft PR I've nosed my way into. Please disregard if still in progress!

[sloanelybutsurely]

@digitalcora lol hey cora! yeah this is just something i pushed up as an example (referenced here #797 (comment))

[sloanelybutsurely]

@digitalcora I've incorporated your feedback to make this a more reasonable refactoring change. I've changed this to only define map_source_config/2 as a private function in Signs.Realtime.

[digitalcora]

✨