Bitmaps returned from this function must have the appropriate scale
factor, e.g. 2 in standard high DPI case, in order to be drawn at
correct size in the ports where logical pixels are different from the
physical ones, such as wxOSX and wxGTK3.
Notably, this allows wxGenericStaticBitmap to work correctly in high DPI
in these ports too.
This also allows to undo some of the changes done in 399b0ff9ae (Use
wxBitmapBundle instead of bitmap scale factor in wxGtkImage, 2021-10-16)
to wxGtkImage code and keep using the same code that had been used
before.
Minimal changes to the code to allow using bigger bitmaps from
wxBitmapBundle in high DPI instead of having to create individual
bitmaps with scale factor greater than 1.
Notice that this is not actually used anywhere in wxGTK yet, but will be
soon.
Document which pointers can, and can't, be null and when exactly is the
stored bitmap valid, as this is far from being immediately obvious.
No real changes.
And use it to get HiDPI support wherever we use GtkImage. This extends and
consolidates support for custom drawing of images which has already been added
somewhat redundantly in several places.
