fix(StopDetailsPage): Distinct errorKeys from API requests on NearbyTransitPage

[KaylaBrady]

Summary

Ticket: 🤖 | Unfiltered Stop Details | Display error banners

What is this PR for?

Solves part 2 of #638.

getSchedule was always using the same errorKey, so a race condition where the nearby transit getSchedule request finishes after the stopDetails request resulted the stopDetails error banner disappearing.

Now, getSchedule and getGlobalData take an errorKey param so the error can be recorded in a context-dependent way.

Additionally, while debugging I noticed that checkPredictionsStale was not being called periodically. This adds that functionality.

Note:
I created a separate ticket to appropriately clear the error banner when navigating between nearby transit & stop details. This is an issue on iOS as well, and is therefore out of scope of this android parity task.

iOS

• If you added any user-facing strings on iOS, are they included in Localizable.xcstrings?
  • Add temporary machine translations, marked "Needs Review"

android

• All user-facing strings added to strings resource
• Expensive calculations are run in withContext(Dispatchers.Default) where possible

Testing

What testing have you done?

• Added unit tests
• Ran locally with hardcoded error for getSchedule for place-pktrm. Confirmed error banner displayed as expected
• Added logs for checkPredictionStale, confirmed it was called multiple times. Not exactly every 5 seconds, so something may be going on there that warrants further investigation, but it was being called on at least some interval.