Don't force fractional scale when toolbar bitmap size is given

The old code in wxToolBarBase::AdjustToolBitmapSize() forced the use of
the exact value of the requested bitmap size multiplied by the current
scale factor, which resulted in ugly bitmaps whenever fractional scaling
factor was used. It also used not immediately clear IncTo() call.

Simplify and improve it by handling the cases when we have a requested
bitmap size and we don't have it differently: if we do have it, just use
it directly, but only with an integer scale factor. And if we don't,
then simply use the bitmap size suitable for the current scale factor.

This seems to result in the most expected behaviour and, notably,
doesn't break the toolbar sample where the bitmap size can still be
toggled between small and big bitmaps on both normal and high DPI
monitors.

Also update the documentation: still recommend not to use
SetToolBitmapSize() at all, but don't claim that it forces fractional
scaling, as this is not the case any longer.

docs/doxygen/overviews/high_dpi.md

@@ -299,7 +299,8 @@ programs involves doing at least the following:
    wxArtProvider::CreateBitmapBundle() (and, of course, return multiple bitmaps
    from it) instead of wxArtProvider::CreateBitmap().
 4. Removing any calls to wxToolBar::SetToolBitmapSize() or, equivalently,
-   `<bitmapsize>` attributes from the XRC, as this forces unwanted scaling.
+   `<bitmapsize>` attributes from the XRC, as this overrides the best size
+   determination and may result in suboptimal appearance.