Fix clipping To Result and With Aspect

This MR addresses issues with the clipping modes "Crop to result" and "Crop with aspect"

**** Please note that this revised code should be tested on Linux or Mac NOT Windows - there seems to be another issue with Windows as noted in issues #7909 and #7575.

These two clipping modes would seem to be a 'lazy' way of cropping a transformed item. For small rotations, for instance, you are likely to get the result that you want but for larger rotations the resulting cropped area may well not be the part of the image that you wanted to keep.

The "Crop to result" setting should identify the largest rectangle that will fit within the 4 or 5 (if near plane clipping is active - see #8021) sides of the transformation polygon. "Crop with aspect" is similar but the largest rectangle has to be of the specified aspect ratio.

To illustrate some of the problems - create a new 600 x 600 image, select the Rotate tool, set Clipping to "Crop to result" and enter 45 degrees in the Angle box then press Enter but DO NOT click the Rotate button. The result is correct - now use the + and - buttons for the Angle field to select angles of 45.1 or 44.9 degrees - the result is far from correct - a thin vertical or horizontal strip.

Again for the 600 x 600 image use the Rotate tool and set clipping to "Crop with aspect" - when the image is rotated the result is failure for all angles - if run from a terminal window the message "no rectangle found by algorithm, no cropping done" will be seen and Clipping is effectively "Adjust"

Create a new image of 6000 x 4000. Use the Rotate tool with Clipping set to "Crop with aspect", set the Angle field to 41.5 degrees - the code again fails to find a suitable rectangle. Then when you commit the rotate you end up with transparent corners - as shown in figure 14.116 in section 4.1.1 of the current version of the documentation - the documentation correctly reflects what the software can do but it shows the code behaving incorrectly (I will raise this as an issue with the documentation if this MR is merged).

Although not using these clipping mode personally it seemed an interesting exercise to try to correct the code. The basic problem is that the current master code has a set series of steps that it follows to get a result but fails to perform any maximization. I have rewritten the code so that it does this. In the case of "Crop to result" the new code takes longer to process although I don't feel that it is unreasonably long. To determine the processing times I added code to the function gimp_transform_resize_crop() so that it looped 1000 times, reading the system time before and after the loops and dividing the elapsed time in msec by 1000. The timings should therefore be qualitative and enable comparison of the old and new code.

The current master code always takes the same time regardless of the size of the image:

For "Crop to result" approximately 11 usec For "Crop with aspect" approximately 13 usec (whether or not it fails or succeeds)

The time taken by the code in this MR varies depending on the size of the image (unless the transformed shape is a rectangle)

When the shape is an orthogonal rectangle - less than 1 usec

Crop to result: 512 x 512 rotated to 45 degrees - approximately 33 usec 1024 x 1024 rotated to 45 degrees - approximately 46 usec 2048 x 2048 rotated to 45 degrees - approximately 52 usec 4096 x 4096 rotated to 45 degrees - approximately 61 usec 8192 x 8192 rotated to 45 degrees - approximately 72 usec 16384 x 16384 rotated to 45 degrees - approximately 79 usec

So roughly 8 usec increase for every doubling of the dimensions - which would suggest that the timing for the maximum GIMP image size would be around 95 usec. Whilst this is slower than the current master code at least it works!

 Crop with aspect:
    1024 x 512 rotated to 45 degrees - approximately 6 usec
    2048 x 1024 rotated to 45 degrees - approximately 7 usec
    4096 x 2048 rotated to 45 degrees - approximately 7 usec
    8192 x 4096 rotated to 45 degrees - approximately 8 usec

So the new code would appear to be marginally faster for crop with aspect that the existing code.