Provide a Gtk.Application and Gtk.ApplicationWindow subclass

[TheEvilSkeleton]

Problem

Given that, eventually, we want to add functionality on either at the application-level and/or top-level instances, such as #838, we'd want a way to make use of those features as easy as possible to use, by providing custom instances. This could also help us handle application-level bugs such as #874. Having a Gtk.Application subclass would also give application developers the opportunity to avoid manually initializing Granite, as they'll be able to just use the subclass.

Proposal

We'd want to have a subclass of Gtk.Application (application-level) and Gtk.ApplicationWindow (top-level window) to open up more possibilities to handle these issues.

Prior Art (Optional)

Gtk.Application subclasses

• https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.Application.html
• https://theevilskeleton.pages.gitlab.gnome.org/libfancy/fancy-1.0/class.Application.html

Gtk.ApplicationWindow subclasses

• https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.ApplicationWindow.html
• https://theevilskeleton.pages.gitlab.gnome.org/libfancy/fancy-1.0/class.ApplicationWindow.html

ShortcutsWindow / CommandPalette

For #838, some inspiration:

• https://theevilskeleton.pages.gitlab.gnome.org/libfancy/fancy-1.0/class.Application.html#shortcuts-dialog
• https://theevilskeleton.pages.gitlab.gnome.org/libfancy/fancy-1.0/class.ShortcutsDialog.html
• https://gitlab.gnome.org/TheEvilSkeleton/libfancy/-/merge_requests/1
• https://gitlab.gnome.org/TheEvilSkeleton/Refine/-/merge_requests/50

[wpkelso]

Also lets us remove a lot of application-side boilerplate for common window accels like Control + q, if those actions are already defined.