chore!: Kill deprecated HasGameRef

[luanpotter]

Description

Kill deprecated HasGameRef - it has become HasGameReference since @spydon has abbreviation phobia.

Checklist

• I have followed the Contributor Guide when preparing my PR.
• 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 or docs.

Breaking Change?

• Yes, this PR is a breaking change.
• No, this PR is not a breaking change.

[spydon]

Lgtm!
There was some talk about also renaming game to something more in the lines of gameRef, iirc @filiph had a good argument for that, but I don't remember what it was. 😅

[filiph]

I don't remember that conversation but I think I can reconstruct my rationale. There's a much larger chance that game will conflict with (shadow or be shadowed) an existing field or local variable than if you choose gameRef.

FlameGame can be "just" the renderer/engine while the "game" (as in, chess game, for example) can be a separate object.

[luanpotter]

I honestly do like gameRef more because for me it clarifies "ownership"; the flame game owns the components, the components just have a "reference" to the parents/game. I know these are just pointers and there is no such concern wrt memory management in Dart, but helps with my own mental model.

The shadowing argument is a good one too, I can definitely see that happening. Since we are now willing to break change, should we consider bringing it back to HasGameRef / gameRef? I know @spydon you don't like abbreviations but I think ref is pretty clear, widely used, and gameReference would be a mouthful. Could also explore other names.

wdyt?