Add an initial version of a preferences dialog

[cameronwhite]

Description of Changes

• Use the libadwaita preferences dialog, and define the layout using a .ui file to test out this process for the first time (works quite well!).

• Move the color scheme preference into the dialog as a test. By adding an event when settings are modified, changes to the settings can be decoupled from the dialog itself

• Add a Preferences menu item. Depending on the platform, this is in the application menu on macOS, or in the Edit menu for a menubar layout on other platforms, or in the main menu when using a headerbar layout.

  • Also simplified logic around how the macOS app menu commands are registered, and adjusted the keyboard shortcut dialog to use different shortcuts from the prefs dialog

• TODO: figure out how to translate the .ui file. If we used the native gettext library for our translations this would just work automatically, so perhaps we should attempt to do this? Otherwise we need to implement a custom loader which translates the xml file using our Translations.GetString() function

Checklist

• This pull request follows the project's contribution guidelines

[badcel]

Great that you like the UI files 👍

If your solution for translations can be supported by GirCore we can try to upstream it or parts of it. There is already a ticket to improve the UI file translation situation but without any concrete idea yet: gircore/gir.core#1482

[cameronwhite]

One option would be to extend the AssemblyResource loader with an additional step that parses the xml file and replaces any translatable strings (probably fairly similar to what the Parabolic app is doing already). The parsing code could be upstream, and then users would just need a way to provide their translation function (e.g. subclassing the default implementation, or implementing some interface that's provided to the loader, etc)
That's probably the most generic way to handle it, especially for apps like Parabolic which have multiple frontends and might want to use some other library for translations

The other approach I've been looking at is just having Pinta use the native gettext functions for its translations, instead of the managed library we've been using - PR #2263. We used to do this back in the GTK2 days, where gtk-sharp had a wrapper Mono.Unix.Catalog

We already bundle libintl since it's used by GTK, libadwaita, etc, so using this is pretty reasonable and just requires a few bindings for the native functions. The .ui translations then just work without any extra steps since GTK translates them using the native gettext library when loading the files

[badcel]

I think you can already provide custom resource loaders so influencing the xml is already possible. Adding another configuration point inside it feels a little much to me.

It sounds pretty great to use the gettext package. One idea which came to my mind is to just let the user use an attribute on assembly level like SetupGettextAttribute(...) which then generates the code inside GirCore.Integration.Initialize();.

In this way if you call it everything gets setup automatically including language and subclass registration.