Various fixes for trimmed sprites and images

[ggcrunchy]

I was doing some art for a project and this involved objects consisting of several parts, like one would have in Spine or Spriter. I used trimming so that I could choose some fixed size, e.g. 512 x 512, and in the image editor just put the individual parts in different layers and draw on those, for my own sanity.

Well, this is all well and good if you just put the sprites and (image sheet-based) images down on the center position and leave it there. But with scaling and rotation (especially with anchoring!) in the mix, problems quickly arise.

This and this, for instance, touch on issues I saw, and maybe this one as well.

@Shchvova I sent you a project I used for testing. As I told somebody else, "The rotating head is way off, the wings break, the legs aren't where their bounds show (the two rects), they "dance", and the collision rect is shifted and oversized."

Basically, the trimming offset needs to be taken into account in several more places.

---

I pulled the frame offset calculation out of ShapeObject::DidUpdateTransform() and into a GetTrimmedFrameOffset() function. The offset will always be retrieved by DidUpdateTransform(), to achieve the current behavior, but in the remaining cases a new flag—enabled via display.setDefault("isImageSheetFrameTrimCorrected", true), initially false for compatibility purposes—will be queried, and when not set the offset will have x and y of 0.

These offsets figure into some operations that traverse the display hierarchy, or the parent chain up to the stage, including the calculation of a display object's transform. They are omitted where the source-to-destination matrix is valid.

---

There are a few "unrelated" additions, though I didn't exactly know that while I was doing them.

---

A group's anchorChildren property won't immediately affect anything; another display property would need to be set, such as x. I've added a fix for this. Per the comment, you have to enable sprite trimming to get this behavior. This is a bit odd; maybe it should have its own default? (At the same time, if you were willing and able to enable a new default, you probably want the sprite corrections as well, in which case adding another would be superfluous. shrug)

---

On that same note, while making sure physics played well, I tried this case:

local physics = require("physics")

physics.start()
physics.setGravity(0,0)
physics.setDrawMode("hybrid")

local g = display.newGroup()
local r1 = display.newRect(g, 200, 200, 80, 80)
local r2 = display.newRect(g, 100, 150, 20, 70) -- extra, since one object will show the issue

physics.addBody(g, "static")

(The body and the group will be in rather different spots.)

This will address that. It's also guarded by the sprite trimming default, like anchorChildren; the same criticisms apply.

---

More of a general sprite thing: some of the frames would be wider or whatever than others, in the same sequence, but the sprite would just blindly use whatever anchor it had, everywhere. I added a new method: sprite:useFrameForAnchors([index]). This will make the frame at index (if omitted, the current frame) normative; any anchor computation is done as if that frame were active.

The index refers to the member of the current sequence, if one is assigned. If the sequence is changed, the sprite will stop watching the frame.

---

I believe that covers it.

[Shchvova]

Looks good. I'll test it and merge

[Shchvova]

Looks good. I'll test it and merge