Obtain ImageData for any requested zoom value, not only autoscaled values

[amartya4256]

This contribution helps retrieve the imageData for the requested zoom by searching for the zoom in the zoomToHandleMap followed by (if not available) scaling the handle at the zoom nearest to it while getting rid of only searching among the autoscaled zoom values.

Contributes to #62 and #127

[github-actions]

Test Results

   486 files  ±0     486 suites  ±0   10m 12s ⏱️ + 1m 35s
 4 309 tests +1   4 296 ✅ +1   13 💤 ±0  0 ❌ ±0 
16 414 runs  +1  16 306 ✅ +1  108 💤 ±0  0 ❌ ±0 

Results for commit 6f047a5. ± Comparison against base commit cec96e9.

♻️ This comment has been updated with latest results.

[HeikoKlare]

It seems to me as if I had misunderstood the original intent of this change. It does not seem to be an actual bugfix but rather an improvement regarding which image data (more particularly, the image data at which scaling) to use for generating the one at the requested zoom level of. Is that correct?

Then of course the kind of test I proposed and is provided in this PR is not a regression test for the change. And probably it's something that we do not even need to test in that way at all.

[amartya4256]

It seems to me as if I had misunderstood the original intent of this change. It does not seem to be an actual bugfix but rather an improvement regarding which image data (more particularly, the image data at which scaling) to use for generating the one at the requested zoom level of. Is that correct?

Then of course the kind of test I proposed and is provided in this PR is not a regression test for the change. And probably it's something that we do not even need to test in that way at all.

In the previous implementation in case of integer 200 scaling, we only allowed the clients to retrieve the imageData of corrected zoom since our initial expectations were that we don't allow images to be created at, for example, the quarter zoom if the quarter scaling is disabled. But since we know that in some cases like Program icons we can get handles of image at these zoom levels, it doesnt make sense to restrict clients from requesting imagedata at certain zoom levels. In other words, this is indeed a feature enhancement as we are now allowing to store any zoom level in the handles map and retrieve them on demand.

Hence, I would not consider this change as a bugfix but rather an improvement. But the tests do make sense to me since it validates the behaviour of getImageData at random zoom levels. It would not be considered a regression test but a feature test.