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.

This PR sets STOP_EVENTS_ENABLED to false. This exposes documentation for the endpoint but all requests will return [] data. I want to leave the actual work of connecting a data source (ideally subsituting the CDN for the S3 Mediator) to a future PR.

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. Do you want a smaller PR? The last endpoint addition was about this big but we could split it into
   1. Model
   2. State mediator + state + parser
   3. api_web
2. 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.
3. 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.
4. How else would you like to see its functionality validated, besides running the app locally?
5. Should we put the route stop_events behind some sort of feature flag? Right now it is shown but not functional without STOP_EVENTS_ENABLED?
6. Are the attributes a little redundant considering the relationships? What are the pros/cons of keeping those attributes?