feat(stop_events): add stop_events endpoint

[runkelcorey]

Summary of changes

Adds the following apps for a stop_events endpoint:

• api_web
  • controller
  • view
• model
• parse
• state

Updates the following apps:

• state_mediator
• api_web/router

I tried not to add any filtering or views that I'm not 100% sure we'd want, such as by parent stop or lon/lat.

How were these changes validated?

• New unit tests for each app
• Ran the server to check docs
• Ran the app locally (I need to configure some env variables)

What questions should reviewers consider?

1. What are the performance or maintainability tradeoffs between using a unique ID for each event and only indices? Like our predictions endpoint, I doubt that users will seek individual events but including it seems to simplify some query patterns.
2. Any thoughts on design patterns here? [Claude and] I tried to be consistent with other modules where there existed a clear way to do things.
3. How else would you like to see its functionality validated, besides running the app locally?
4. Currently, flashback outputs a file structured hierarchically, similar to TripUpdates_enhanced. However, the API parses that structure back into individual events. So, internally, the representation is event-by-event. It seems unnecessary to have code that nests and then unnests the structure. Is the only drawback to removing the unnesting and storing stop_events as events the size of the file in s3?