I tried to make it compatible with other platforms in the future.
Android has a different API.

 1. Do them inside of the AppleSystemContextMenuItem. That requires me
    to move that class to the widgets library. Not possible with sealed
    class?
 2. Do them inside of SystemContextMenu. But then it messes with the
    `json` method of SystemContextMenuItem. That would need the
    localized title in order to work.
Maybe there are 2 concepts here. One has to be the class that's
presented to the user (currently AppleSystemContextMenuItem), which
needs to be compact and understandable. The pure data representation.
The other is the data that is sent to the engine. Currently my problem
arises because these concepts are mixed: AppleSystemContextMenuItem
tries to provide a nice API to the user while also providing a toJson
method that talks to the engine.
Separate these two ideas. The user-facing thing shouldn't know about the
engine json. Maybe SystemContextMenu should do that conversion, since it
knows about both of these concepts and also has the localizations.

I've put all the localization logic in SystemContextMenu. The Items just
contain dumb data and don't know anything about their conversion to
json. I think this way is a lot better, but I should give a pass through
to clean up and see if I can improve the architecture more.

Really needs cleanup though, and I have to remove the custom buttons
stuff from this PR anyway. So next I should decide on the non-custom API
in a way that works nicely with custom buttons in the future, then once
that's solidified, delete the custom button stuff.

Both SystemContextMenu.items and SystemContextMenuController.show.
Somewhat concerned about all of the sealed class stuff...
Still considering moving/isolating the json stuff.

Reduced lines of code in respecifying title/onPressed.

No way to know if there is another SystemContextMenuController somewhere
in the app! Also, that's how it was before this PR.