refactor: Remove Loadable, optional onLoads

[st-pasha]

Description

1. Game no longer depends on Loadable, that is, when creating a new Game subclass you only need to say class MyGame with Game instead of class MyGame with Loadable, Game. This is done by moving the 2 lines of code that are inside Loadable into the Game class. The benefit here is that it simplifies the usage of the Game class.

2. Component no longer depends on Loadable. This brings in several advantages:

   • Conceptually, Component is the most "base" class in the Flame engine. Having it being derived from some other helper class is not ideal.
   • The onLoad method is now defined within the Component class, alongside all other lifecycle methods, which makes it easier to document.
   • The onLoadCache variable is removed -- the fact that the component is loaded only once is guarded by the isLoaded flag, so carrying around that Future was unnecessary and was only increasing the size of the Component object.

3. Loadable mixin is now empty and declared Deprecated, to be removed in 1.2.0. Anyone who uses a custom Game class via with Loadable, Game can simply remove Loadable from the declaration.

4. The default onLoad methods are no longer declared as @mustCallSuper, since they have no functionality. This simplifies user code: there is no longer need to say await super.onLoad() at the start of your onLoad() implementation. A derived class can always re-add this annotation if it overrides onLoad and if it intends to be derived further.

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.
• 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.

[wolfenrain]

We could remove the breaking change by having an empty Loadable mixin right? And then just deprecated it for the next breaking release?

[st-pasha]

We could remove the breaking change by having an empty Loadable mixin right? And then just deprecated it for the next breaking release?

Yeah, makes sense, let's do that.

[spydon]

Lgtm! Don't remember why I created that mixin from the beginning, but this is clearly nicer.