faster loading of font list

Supersedes !2536 (closed)

/cc @CRogers @doctormo @jabiertxof @speleo3

AFAICT, there are basically two very slow, related things:

• computing the height of cells, and rendering text in various fonts in them. To solve the first one, I declare that all cells are 30px tall, period. another option would have been to use gtk_cell_renderer_text_set_fixed_height_from_font which is more compact but gets its results wrong when fonts have a big ascender value. (basically "big" fonts are not visible), so I tested and 30px came as a decent value.
• rendering text with markup using different fonts is slow when done in a non-yet-layout cell. This came as a surprise, as rendering in an already existing cell is fast, and rendering with default font is fast... so I think what happens is that even when told to use a fixed height, the text is still used to compute a requested height when the cell does not exist yet, maybe it does not yet has the information that its height is fixed.

What this MR does is that on the first click on the popup for fonts, which was already buggy (no scrollbar), the whole dropdown is computed without using fonts. This makes it fast.

Then, on the second click, the rendering method is changed to use the fonts, and it's much faster since it uses already layouted cells.

As I mentioned on IRC, given how gtk does things, the only way to "really" fix that dropdown would be

22:03 < Mc> cellrenderrer is ok (and fast) if we give it a filtered model with a start and end position in the whole model, but we need to decouple the entry 
    (which needs to keep the whole model) and the dropdown, which needs to keep an internal state, so it needs to be reimplemented as a gtkwindow contianing a gtkbox 
    containing the gtklistview with the current cellrenderer + a custom gtkscrollbar being able to change the filter data of the gtkffilteredmodel
22:04 < inkchatbot> <doctormo> That's a lot of code
22:04 < Mc> then we will only render what is actually shown, because that way we won't use a kilometer-long scrolledwindow but only an area with a size that fits on the screen
22:04 < Mc> honestly it *should* be what I would expect gtk to do, but no, the way it's done is to render a kilometer-long scrolledwindow
22:05 < inkchatbot> <jabiertxof> In GTK4 there is new list with only render visible area