Component.priority discussion

This is a discussion for the evolution of the component's `.priority` system.

### Current situation

Every `Component` has the `int priority` property, which determines that component's sorting order within its parent's `children`. This approach works for many games, but for some becomes a hindrance, or even necessitates creation of a parallel "priority-like" system.

### Ideal future state

The "priority" mechanism of the `Component` is replaceable and highly customizable, just like everything else in the Flame engine. Maybe it becomes a mixin, or in some other way.

The following priority systems should be provided:
- no priority -- in some simplest games the priority system may not be needed at all;
- `int priority` -- same as the current system;
- `double priority` -- similar to the current approach, but uses floating-point priorities. This is useful in cases when the "priority" is just the distance to the camera, in which case it makes sense to have this distance to be `double`;
- computed priority -- the order of elements changes dynamically on every game tick. This is useful for games with isometric projection, where priority is just a function of (x, y) world coordinates of the component;
- range priority -- used in games where the components are "fat" in z-direction: instead of having a fixed distance to the camera, the components may contain sub-parts at different distances from the camera;
- user-defined priority -- users should be able to implement their own priority mechanism if they wish so.

### How to get there

The specifics of the design of the component priority system **need to be discussed**. In particular, we would want to minimize the amount of breaking changes for our users (though understandably this will be breaking), and if possible go through the deprecation cycles.

One aspect of the transition, which we can implement right away, is to **deprecate** the `priority` argument in the `Component` and derived classes, and instead recommend using the `priority` setter, which has been implemented recently. Thus, we would recommend users to replace
```dart
MyComponent(priority: 7)
```
with
```dart
MyComponent()..priority = 7;
```