gui.messageBox does not allow button renaming

[XLTechie]

Is your feature request related to a problem? Please describe.

I was trying to implement some code for a proposal of a UX bug fix.
It would have been convenient to use a dialog containing "Cancel" and "Continue" buttons.
If I was to do that in an add-on, it would be straight forward:

1. Call wx.messageDialog, with the wx.OK | wx.CANCEL flags, in a context handler.
2. Then call .SetOKLabel("Continue") on the context handler instance.

However, the docstring for gui.messageBox states:

This should be used for all message dialogs rather than using C{wx.MessageDialog} and C{wx.MessageBox} directly.

Describe the solution you'd like

1. I would like there to be an explanation in the docstring, to say why this requirement exists, rather than the next developer facing this having to hunt the reasoning down through code analysis and git blame.
2. I would like gui.messageBox to accept keyword arguments allowing the restyling of buttons via wx.Set[BUTTON]Label calls.
3. Obviously, this would necessitate a change from wx.MessageBox, to wx.MessageDialog internally. I don't know if doing that would present any complications (I don't know of any, but I am no wx expert).

Describe alternatives you've considered

See #12353 for a potentially more acceptable alternative.

Additional context

This appears to have been introduced by @jcsteh in 3ebc8fd, as a means of preventing message dialogs and settings dialogs from stepping on each other and causing strange behavior (freezes), by being open at the same time.

Therefore I'm not suggesting relaxing the requirement to use gui.messageBox. I merely ask that we be able to expand its capabilities a bit.

[XLTechie]

For what it's worth, I have made the change to wx.MessageDialog inside of gui.messageBox, and have added keyword arguments for the various Set*Label(s) calls, in a test build.
I have yet to notice any ill effects after several hours of use, but I will keep running it to see if anything unusual happens.

[CyrilleB79]

Reopening as #17304 has been reverted in #17561.