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.
Introduce unit tests covering parsing for the originally introduced
filtering features. The introduced improvements (lower and upper
interval and decimal point support) also tested.
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.
For the sake of testability without having to spin up visual tests,
extract methods related to parsing filter queries from FilterControl
to a static FilterQueryParser class.
