feat: Current elevator closure layout

[cmaddox5]

This PR adds a new layout for elevator screens. When the current elevator is closed at all, we show this layout that helps riders get to an alternate elevator. Maps will be created by Betsy and added to S3. Coordinates for the map marker will also be provided by Betsy.

Config that can be used for testing:

{
  "ELE-101": {
    "disabled": false,
    "name": "",
    "app_id": "elevator_v2",
    "app_params": {
      "evergreen_content": [],
      "elevator_id": "842",
      "alternate_direction_text": "Alternate direction text goes here. This is the largest body text class. Use this for shorter sets of directions. Add up to 6 lines at this size",
      "accessible_path_image_url": "images/elevator/maps/forest-hills-map.png",
      "accessible_path_direction_arrow": "e",
      "accessible_path_image_here_coordinates": {
        "x": 151,
        "y": 182
      }
    },
    "device_id": "",
    "hidden_from_screenplay": false,
    "refresh_if_loaded_before": null,
    "tags": [],
    "vendor": "mimo"
  }
}

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1208677840815945

[digitalcora]

Approving with one suggestion, take it if you'd like — this is now over a week old (though I know holidays etc.) and seems in good shape, so I don't want to hold it up any further!

[digitalcora]

We might have already talked about this, but I think it could be worthwhile to move this conditional to the widget generation. This single "widget" is basically two widgets in a trenchcoat — we always send over all the fields for both, and then throw half of them away, depending on a condition the server itself could easily check. In other words, we could instead have a CurrentElevatorClosed widget and an OutsideClosures widget on the backend, each populated with only the fields needed for that "view".

I could be missing something about future plans for this widget that might require it to have access to both sets of information at the same time, though.

[cmaddox5]

Big fan of that approach. That would likely be a pretty big diff though. You think it makes sense here or should I create a followup PR?

[digitalcora]

I think within this PR is actually the best place for it, since this is where we're introducing the second widget. Else we'd have (in the final commits on main) one commit that adds the widget using this approach, and a second that completely changes the approach. That's a lot of extra, and ultimately pointless, information for anyone looking at history to sort through.

I'm happy to quickly re-review the change if you want one more look at it.

[cmaddox5]

Should be good to go if you want to take a look.

[digitalcora]

Looking good!

[digitalcora]

I don't know if we really need all these "it does the thing" tests for functions whose implementation is extremely basic... ideally the code paths would be covered by some higher-level test, but we have no such category of tests at the moment. Guess I won't make any specific recommendation here, just noting that it's an unfortunate situation.

[cmaddox5]

I have this thought every time I make tests for a new widget. Definitely a good idea to put end-to-end framework tests on some kind of radar. Not sure if that's big enough to be roadmap worthy or if a simple tech-debt task would be sufficient?