Nested affine transformations are not working properly

[X512]

This is hrev54241.

Steps to reproduce:

1. Install ​https://github.com/X547/HaikuUtils/tree/master/PictureView.
2. Open attached TigerClip picture.
3. Try to move or scale picture. Only clipping will be affected, tiger image will be not transformed.
4. Try to resize window by left or to side by using right mouse button. Tiger image will shift in direction opposite to scaling.

[pulkomandy]

Things I remember about this:

• The ScrollBy and SetScale calls are from BeOS, and they don't do the same thing as TranslateBy and SetScale.
• TranslateBy, RotateBy and ScaleBy modify the current transform, but SetTransform resets it to a new state
• It is possible to "nest" transform in two ways, with and without an intermediate PushState/PopState. The effects are different. Basically the idea is that if you do a SetTransform(), and another SetTransform(), only the later is used. But if you do SetTransform(), PushState(), SetTransform(), the global result is that the transform matrixes are multiplied together.
• The various clipping methods behave differently. ClipToRect always works in view space (affected only by ScrollBy and maybe ScaleBy). This is because it desirable to clip drawing according to what parts of the view are invalidated (typically in a Draw() call you would do ClipToRect(updateRect) or something like this). On the other hand, ClipToShape takes the transform into account.
• I'm not sure anymore in which case ClipToPicture falls.
• Things can get even more complicated if you have transparency layers, and even more so when you do a 'clipping' (to shape or picture) with partial opacity.
• ClipToPicture has the additional problem that a BPicture has no guarantee that it will draw the same thing everytime. It can depend on the current state of the view (high and low color, pen size, transform and scrollby/scaleby, ...).
• The ScaleBy API is difficult to use because it does not allow setting a neutral/center point for the scaling as you'd expect. Intuitively it would use B_ORIGIN, but that leads to unexpected results if you have translated the view with TranslateBy. Same thing for RotateBy, it would be easier to use if you could specify a center point around which to perform the rotation.

[waddlesplash]

Fix merged in hrev54314. Thank you!

[waddlesplash]

Change reverted in hrev54315 due to build breakage.

[waddlesplash]

New version applied in hrev54316.

[pulkomandy]

Move closed tickets into beta3 milestone