Improve ConfirmDialog and automatically handle managed UI objects

[falko17]

ConfirmDialog improvements

This moves the ConfirmDialog out of the Drawable directories, since it is used in more situations than Drawable-specific menus.

Additionally, some minor refactorings and improvements were made, notably:

• The dialog is now more configurable. Specifically, the title, description, button texts, button icons, and button colors can all be set to custom values.
  There is also a pre-made configuration for delete confirmations.
• The visuals of the dialog have been slightly changed. For example, the confirm button is now green by default, the dialog is slightly larger, there are icons on the buttons, and so on.
• The dialog should now be able to handle differing text lengths better.
• A static convenience method has been added to make it easier to ask the user confirmation questions.
  It suffices to call this static method on the class with the desired configuration (i.e., message etc.) and then await the result (see below), without the need for the caller to have access to a fitting GameObject for the dialog (or needing to handle destroying it).
• The dialog has been turned into a PlatformDependentComponent.
• A fade-in and fade-out animation has been implemented for the dialog.
• Instead of utilizing callbacks, the method to show the dialog now leverages its asynchronous nature by simply waiting until the user made their choice, then returning a boolean indicating that choice.
  This should also more easily enable patterns such as early return, as is commonly done with, for example, the analogous window.confirm() method in Web development.
  As a concrete example, the following is now possible:

if (!await ConfirmDialog.ConfirmAsync(new(message)))
{
    return;
}

To give an example of the visual changes and customizability, here's a before and after:
$\Longrightarrow$

Additionally, the user is now asked for confirmation before a keybinding is rebound, fixing #683.

Automatic handling of managed UI objects

This commit abstracts away a common behavior of PlatformDependentComponents (PDCs). It's now possible to place an attribute on members of PDCs like this:

[ManagedUI(toggleEnabled: true)]
private GameObject someUI;

This will cause the someUI game object to be enabled/disabled whenever the PDC it's contained in is enabled/disabled. By default, it will also cause someUI to be destroyed whenever the PDC is destroyed. Additionally, if integral: true is specified, this will work the other way around as well: The PDC will be destroyed as soon as someUI is destroyed.

It's possible to place this attribute on both GameObjects and MonoBehaviours, as well as on enumerables of such Unity objects. It will then be applied to each of the contained objects.

Existing PDCs have been refactored to use this new functionality.

[github-actions]

There are a few bad patterns I found which you should check.

[Cyclone1337]

Thank you for your pull request. I didn't encounter any errors during execution.
Your feature brings many great improvements to the ConfirmDialog, and I really like the new configurations. I especially appreciate the integration via ConfirmConfiguration.

However, we should keep in mind that the Pause key is a poorly chosen key for the settings menu. Not every laptop has this key. In fact, typically would an user expect the ESC key to be used for this, as is the case in all other games.

[falko17]

Thank you for the review, @Cyclone1337!

However, we should keep in mind that the Pause key is a poorly chosen key for the settings menu. Not every laptop has this key. In fact, typically would an user expect the ESC key to be used for this, as is the case in all other games.

And yes, I absolutely agree—ESC seems like a much more natural choice. Currently, ESC is used for cancelling any actions, which also makes sense to me. Perhaps we should redesign the key binding system to allow for one key to be used for multiple situations? This could also help curb the large number of keybindings we currently have.

[koschke]

@Cyclone1337 @falko17 It looks like this PR was approved. Can I merge it?

[falko17]

It looks like this PR was approved. Can I merge it?

Yes, I think you can go ahead—I've addressed all of @Cyclone1337's review comments now. Though you can take a second look at my changes, if you want to.