Introduce an IBarLine interface, which together with generic constraints
helps decouple BarLineGenerator from the actual hitobject types it
creates. Thanks to this, all rulesets that want bar lines can provide
an implementation of IBarLine that also derives from the base hitobject
class.
This allows DrawableBarLines in taiko and mania to be migrated back to
DrawableTaikoHitObject and DrawableManiaHitObject base classes
respectively. This in turn resolves#6215 without code duplication,
since the missing anchoring application is now done in mania's
DrawableBarLine through deriving from DrawableManiaHitObject.
Due to floating-point rounding and representation errors, filters could
wrongly display results incongruous with the wedge display text (ie.
a beatmap with the BPM of 139.99999 would be displayed as having 140
BPM and also pass the bpm<140 filter).
Apply tolerance when parsing floating-point constraints. The tolerance
chosen is half of what the UI displays for the particular values (so
for example half of 0.1 for AR/DR/CS, 0.01 for stars, etc.)
Tests updated accordingly.
To match stable, add creator= and artist= filters to the beatmap
carousel on song select screen. Contrary to stable, this implementation
supports phrase queries with spaces within using double quotes.
The quote handling is not entirely correct (can't nest), but quotes
should rarely happen within names, and it is an edge case of an edge
case - leaving best-effort as is. Test coverage also included.
Culture was not taken into account when parsing filters, which meant
that in cultures that use the comma (,) as a decimal delimiter, it would
conflict with the comma used to delimit search criteria. To remove
any ambiguity, introduce local helper functions that allow the decimal
point to be utilised, using the invariant culture. This also matches
stable behaviour.
The decision to not reuse osu.Game.Beatmaps.Formats.Parsing was
deliberate due to differing semantics (it's not really sane to throw
exceptions on receiving user-facing input).
A single IsInclusive field causes unexpected issues when trying to
formulate a half-open interval query. Split out IsInclusive into two
fields, Is{Lower,Upper}Inclusive and update usages accordingly.
