Make image-quality more consistent

[72374]

See commit-descriptions for more information.

[72374]

Here a comparison for the quality of images sent in chats.

Tap here to view the original images

	Whole image	Cropped to relevant content	Further cropped to 1280 pixels	Whole image cropped to square
Original image	3840x2128 = 8,171,520 pixels	3521×990 = 3,485,790 pixels	1280x990 = 1,267,200 pixels	2128x2128 = 4,528,384 pixels

After sending	Whole image	Cropped to relevant content	Further cropped to 1280 pixels*	Whole image cropped to square*
Main branch	1280x709 = 907,520 pixels	1280x360 = 460,800 pixels	1280x990 = 1,267,200 pixels	1280x1280 = 1,638,400 pixels
This PR	1719x953 = 1,638,207 pixels	2413x678 = 1,636,014 pixels	1280x990 = 1,267,200 pixels	1280x1280 = 1,638,400 pixels

*: The 2 columns on the right are supposed to be identical; i mostly included them, to make it visible that square-ish images already get encoded with up to ~1.6 megapixels, on the "main"-branch.

[iequidoo]

Commit message "chore: Move the definition of the target_wh-variable" should be "refactor:".

Commit message "feat: Use the available file-size for avatar-images better" -- better tell what it actually does briefly, i.e. "feat: Change multiplier to 7/8 when scaling down huge avatars". Long explanation message can be left as is.

[iequidoo]

When saying that the number of JPEG blocks matters, i meant that i'd rewrite this in the way like

let mut resolution_limit =
    (f64::from(n_px_longest_side) * (f64::from(max_wh) / (n_jpeg_blocks_sqrt * 8))) as u32;

When calculating n_jpeg_blocks_sqrt, we should ceil both dimensions of course.

And i think, the while loop below can be removed, it's not a problem even if both dimensions aren't aligned to 8 px, the main thing is that the whole image doesn't contain more JPEG blocks than max_whxmax_wh one contains.

[72374]

I removed the while-loop, and also tried using the JPEG-block-count (converted back into pixel-count by multiplying it with 64, where it was necessary), but there was no noticeable benefit, when i tested it with various images; and when testing that with a series of 10 images with 1 pixel of resolution-difference each, the changes in file-size and resolution of the encoded images were less consistent, than the current code.

So, i suggest using the current, simpler code.
If there is a concrete benefit when the target-resolution is set based on 8x8-blocks of pixels, the code can still be changed later.

[iequidoo]

Then let's bring back the while loop again, it does almost the same job :) Why i suggested to remove it is that while you're trying to align the longest side to 8 px, you may lose the 8-px alignment for another side (which wasn't checked). But this is a corner case, most of the time this won't happen. A coment on that will be helpful also

[iequidoo]

But basically the probelm is this: imagine you have a 234057 x 7 image. Overall the number of pixels fits into limit for a 1280 px square (but not the number of JPEG blocks!). Then the while loop will reduce it to 234056 x 7. Still, the number of JPEG blocks will exceed the one for the 1280 px square, this is unfortunate because we now have lower byte quota per JPEG block.
...
Such an image should be reduced to 204800 x 6 ideally.