feat!: Added getImageLayer to flame_tiled

[munsterlander]

Description

This is a very simple add to flame_tile to allow getting image layers.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the
relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• The title of my PR starts with a [Conventional Commit] prefix (fix:, feat:, docs: etc).
• I have read the [Contributor Guide] and followed the process outlined for submitting PRs.
• I have updated/added tests for ALL new/updated/fixed functionality.
• I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• I have updated/added relevant examples in examples.

Breaking Change

Does your PR require Flame users to manually update their apps to accommodate your change?

• Yes, this is a breaking change. (Indicate it in the [Conventional Commit] prefix with a !,
  e.g. feat!:, fix!:).
• No, this is not a breaking change.

[ufrshubham]

I was thinking should we make it a generic method

T getLayer<T extends Layer>(String name){
    final t = map.layers.firstWhere((layer) {
      return layer is T && layer.name == name;
    });
    return t as T;
}

[munsterlander]

Which I concur with and if @spydon wants to implement this, then we can go in and change all the docs, examples, and tests. It is a breaking change though, so I don't know if a phased approach is better, i.e. have all 5 methods co-exist and mark the specific implementations as deprecated (even though 3 would be new), have just 2 methods and mark the old as deprecated with the generic one there, or just break it and only have 1.

[munsterlander]

Documenting implementation in case there is a question:

getLayer<ObjectGroup>("myObjectGroupLayer");
getLayer<ImageLayer>("myImageLayer");
getLayer<TileLayer>("myTileLayer");
getLayer<Group>("myGroupLayer");

[st-pasha]

1. Looks like the three functions can be combined into a single template function.
2. Please use doc-comments (///) for documentation. You may read more about them in this guide.
3. Consider what would happen when the map doesn't have the requested layer.
4. Perhaps add a few tests?

[munsterlander]

@st-pasha Yes, ideally it can return null to avoid errors with calls to non-existent layers. Ok, I will update this pr with the relevant change. Do we need to leave the existing method and just label it as deprecated?

[st-pasha]

Do we need to leave the existing method and just label it as deprecated?

yes, breaking changes should be avoided if possible. So, leaving the existing method as-is and marking it as @Deprecated() is the right idea.

[spydon]

Looks good, I agree with @ufrshubham that it would be nice as a generics method, and with @st-pasha regarding the test, deprecation and docs.

[munsterlander]

Ok, I think that does it. We added the code, tests, examples, doc block, and docs. I updated the PR to indicate blocking and remove unnecessary comments. I also have pulled in the upstream changes.