simplify box creation and layout

[dterrahe]

This PR has three main goals:

• Simplify creating simple widget interfaces in modules and dialogs. These usually involve a number of nested horizontal and vertical boxes, that first need to be created and then filled using individual calls to gtk_box_pack, which takes, for newcomers, unintuitive parameters. The new dt_gui_vbox and dt_gui_hbox combine the creation and adding a list of widgets in one go. This also makes them nestable. For already existing boxes, use dt_gui_box_add to add a list of widgets. The resulting code is often more compact and, when all widgets are added in one go, makes the intended layout more easily discernable and amendable. This PR is intended as a showcase with many examples.
• Gtk4 will do away with gtk_box_pack and the fill and expand child properties it sets. Instead, the same effect has to be achieved using h/vexpand and h/valign. Using these now should make eventual porting somewhat easier (ideally only requiring a trivial change in gtk.c). It also drops the idea of packing widgets either at start or end of the box. Aligning buttons to the right can now usually be achieved by wrapping the first one in dt_gui_expand before dt_gui_box_adding it. Buttons then should no longer be added in reverse order.
• Error handling is improved. There's no need to cast different types of widgets to GTK_WIDGET when adding them to an dt_gui_v/hbox and there will usually be a more helpful error when an uninitialised widget is added. Something like
  5.5440 [...]/src/develop/blend_gui.c:3734 dt_iop_gui_init_blending: trying to add invalid widget to box (#2)
  Again, this should hopefully be helpful to newcomers.

@ralfbrown since you've been doing a fair amount of gtk work recently, would you have any suggestions? Looking, for example, at the changed code in splash.c

This PR at the moment converts about 100 calls to gtk_box_new and 300 gtk_box_pack_start/end. There are 400 and 900 remaining, so still a fair bit of work. I'm unlikely to do all of it, so help is needed. Some of that work should allow for opportunities to simplify/improve/correct/clean, so it is not a completely mindless conversion, but on the other hand, it could be something for a dedicated new contributor to bite into. In the end the intended result is that "nothing changes", so testing should be straightforward. I am willing to do a limited amount of review/mentoring. A FR marked "good first contribution" could be raised (after this is merged).

[jenshannoschwalm]

Works nicely here.