Add support for tile image rects in image collection tilesets

[aleokdev]

Wasn't sure whether to put these members inside of TileData or put them in an external struct. Finally I ended up creating a new structure to hold them, but feel free to discuss against it.

[bjorn]

I know in the file format this information is currently only used for image collection tilesets. However, internally Tiled also uses it when tileset images are used. So I wonder if it would make sense to not make the image_rect optional, since it would actually be useful to provide this information in that context as well (see #166).

The long-term plan for storing each tile's image rect is to also be able to work with a texture atlas with varying tile sizes, and to improve the handling of expanding the image (when storing each tile's rect, image can be expanded at right and bottom sides without invalidating existing tiles).

Whether this should be a separate struct or not... I don't have a strong opinion. In Tiled I used a QRect just because I had it available and it makes it convenient to pass around. If Rust had a generic rectangle type it might make sense to use it instead, but the ImageRect struct is fine too.

[aleokdev]

About calculating the image_rect at load time: To my understanding, the <image> tag inside the tileset may appear after any <tile> tag, so the image is not available when loading (Thus we cannot calculate the image rect). Maybe we could just add an image_rect fn to Tile apart from the member in its TileData which returns either the stored image_rect or calculates it from the parent tileset.

[ElnuDev]

Any updates on this? This would be nice to have, as (to my knowledge) tile image rects are the way you're supposed to slice multiple sprites that are packed into a single spritesheet for multiple objects. Any easy workaround for now is just to copy all of the rect parameters as custom properties, but it is a bit clunky.

[bjorn]

Right, I guess an optional image_rect works fine and we can indeed later add a function to Tile that will return this when it is set, or dynamically calculate it as suggested by @aleokdev. This can be merged as-is!

[aleokdev]

Great, will try to merge today after work.

[aleokdev]

Sorry for the delay once again.