Tidying some dialog-related code

[Lehonti]

The changes to EditCanvasGridAction, specifically, are a demonstration that will help us start discussing a point.

I wanted to change some code in StatusBarColorPaletteWidget and NewDocumentAction so that their dialog code uses async and await. However, doing it the way I'm doing it with other dialogs means that I would be accessing its properties after it has been Destroyed. That would work because the properties are custom, from the Pinta codebase, and in no way tied to the lifetime of the Gtk dialog in question. However, it doesn't feel that clean.

If we just need to read the values, I was thinking we could create specialized extension methods and using them instead of the generic dialog methods, something like:

public static Task<NewImageInfo?> RunAsync (this NewImageDialog dialog) {
    Gtk.ResponseType response = dialog.RunAsync();
    if (response == Gtk.ResponseType.Ok)
        return new (NewImageSize, NewImageBackground);
    else
        return null;
}

It's also tricky because the dialog is still visible even after it's Disposed, unless we Destroy it previously, which doesn't make a lot of sense to me. One possible way to address that is creating our own base dialog class with an overridden Dispose method, or perhaps even address it directly by making the appropriate changes to gir.core.

If we are not just reading its properties, but also calling a method with side effects, (see dialog.RevertChanges()), it's a bit trickier to do cleanly, but in this PR I'm proposing a temporary solution, although in my opinion this RevertChanges method, along with the CanvasGridManager, should be refactored out of the dialog, because a dialog has no business changing the workspace, but rather should just be used for getting input from the user.

[cameronwhite]

Having a dialog define its own RunAsync () method seems reasonable if the dialog should return something other than the basic response types. I assume it could even be defined on the class itself rather than an extension method?

gtk_widget_destroy can have additional behaviours that are different from just adjusting the reference count, which is what Dispose() does, so calling destroy right before returning the result value seems reasonable. I agree that it would be better for any code called after the dialog is done to live elsewhere, like in the calling code, to reduce mixing of UI and actual logic

[Lehonti]

Thank you for the feedback! I will keep it in mind as I refactor the other dialogs.

As for the dialog for showing the grid, I moved the code that modifies the canvas grid out of the class