refactor: Resize logic in GameRenderBox

[st-pasha]

Description

The documentation of RenderBox says the following:

/// When implementing a [RenderBox] subclass, one must make a choice. Does it
/// size itself exclusively based on the constraints, or does it use any other
/// information in sizing itself? An example of sizing purely based on the
/// constraints would be growing to fit the parent.
///
/// Sizing purely based on the constraints allows the system to make some
/// significant optimizations. Classes that use this approach should override
/// [sizedByParent] to return true, and then override [computeDryLayout] to
/// compute the [Size] using nothing but the constraints, e.g.:

This PR changes GameRenderBox to adhere to this advice and set sizedByParent to true.

Checklist

• 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.
• (NA) I have updated/added tests for ALL new/updated/fixed functionality.
• (NA) I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• (NA) I have updated/added relevant examples in examples.

Breaking Change

• No, this is not a breaking change.

Related Issues

Maybe helps with #1293 ?

[luanpotter]

don't you still need to update the size variable when flutter changes our size?

[st-pasha]

That's what I thought at first too, but it turns out https://github.com/flame-engine/flame/blob/main/packages/flame/lib/src/game/game_widget/game_widget.dart#L319 already does that.

[luanpotter]

Nice!

[spydon]

Seems like @renancaraujo changed it the other way around here:
#845

[renancaraujo]

Makes sense now.