Add support for buttons in autosplitter settings

[caeyo]

Implements support for buttons to be added by LiveSplit/livesplit-core#949.

• Adds export_settings_buttons!() so authors opt in to the on_settings_button export (pulls the key, then dispatches)
• Adds settings::gui::add_button(key, description, on_click) to register a host button and a guest handler in one call
• Adds #[derive(Gui)] support for Button fields with #[button(on_click = ...)]

[AlexKnauth]

I don't understand why much of this complexity should be needed. Auto-splitters can already do button-like functionality via a boolean/checkbox field, that the user can check to "press" it, and that the auto-splitter can set back to false as it performs the action. A wrapper around that to show a button instead of a checkbox should theoretically be simpler than the complexity I see here... unless there's a greater reason for it that I haven't looked deep enough to see yet

[caeyo]

Relying on the settings map state as the communicator of button events is potentially brittle, nothing extreme but there are various issues I can think of:

• If a click isn't consumed properly (autosplitter crash, autosplitter blocked waiting for game attach, etc.) it gets saved to the settings map as "pending". It will then be fired at a later point without any click having been performed - worst case on a separate session entirely
• Click handling becomes dependent on autosplitter refresh rate, and may restrict autosplitter devs to certain refresh rates that would otherwise be unnecessary in order to have a responsive UI
• Two clicks between polls will collapse into one due to a lack of synchronous execution

I don't believe there's that much complexity here, it's fairly standard callback handling and the proposed approach invites its own issues + would be a little strange to bake in something that's very much a workaround for more correct callback messaging

[AlexKnauth]

If a click isn't consumed properly because the autosplitter is crashing then you got bigger problems, the callback method isn't going to be any better in that case.

For "autosplitter blocked waiting for game attach", the solution to this is to call a function that checks the settings map for this in between game attach attempts. avoid calling wait_attach when your autosplitter wants this button functionality, and instead call normal attach in a retry loop that does this button checking in between. that's what I've done for both the Silksong autosplitter and the cross-platform version of the Hollow Knight autosplitter, and it's worked well enough for those, though admittedly not as good as a dedicated Component with full winforms access.

For refresh rate concerns, if the user is expecting the settings to change somewhere else as a result of the button press, those would only happen on the next refresh anyway, right? So I don't see much of a difference there.

With a button wrapping around a bool, the various front-ends could easily disable the button and show it as greyed-out until the autosplitter handles it and sets the bool back to false, and that would prevent the problem of two clicks collapsing into one, though it would limit the rate at which the user could press it many times in a row.

[caeyo]

What you've laid out still has concessions that, in the face of more involved code, don't feel worth conceding to me. I leave it up to a maintainer to decide