Until now, the implementation of the overrides in `SelectionBlueprint`
have been confusing to the point where I would just implement by
trial-and-error (or copying from an existing implementation). This was
due to a combination of using "object" space coordinates
(ie. the thing the `Blueprint` is operating on) and screen-space coordinates.
This change switches all event related coordinates to screen-space,
which is how we already handle rotation/scale operations. With the
introduction of other editor types where the related objects are
drawables, this also makes a lot more sense.
Previously, non-pooled DHOs were immediately added as children of the HOC when Add is called. Also, non-pooled DHOs were always attached to the HOC as children.
New behavior is that non-pooled DHOs are only added after CheckChildLifetime, and only attached to the HOC while the DHOs are alive.
- LifetimeManagementContainer inheritance of HOC is removed, as it is now all DHOs are "unmanaged" (previously `AddInternal(false)`).
- The signature of `Clear` is changed, and it is now always not disposing the children immediately.
Here we use `IHasColumn` to support rulesets with columns, and so I moved that interface out into `osu.Game` from `osu.Game.Rulesets.Mania`.
We also use the same threshold as the unsnap check to ensure that no problems slip through. Specifically where an object is simultaneously not concurrent and not unsnapped but still on the same tick.
While it is the case for the existing official Skills, Skill implementations shouldn't be required to conform to a strain based approach.
There are other valid approaches to calculating skill difficulty that can be supported by abstracting the strain logic into its own StrainSkill class.
As strains are an implementation detail of the current Skill calculations, it makes sense that strain related logic should be encapsulated within the Skill class.