Add last played search filter in song select

[Elvendir]

Answers #22908.

Adds date criteria for search filter in song select.
Adds corresponding Tests.
InspectCode.ps1 run.

Date criteria is an OptionalRange<DateTimeOffset> to be inline with the dates in BeatmapInfo.

tryUpdateDateRange updates the criteria:

• accepted format are: any combination of 0y 0M 0d 0h 0m 0s where 0 can be any double as long as the order yMdhms is respected, and any double that will be converted to days (as in stable),
• dateTimeOffset.Add#### is used to move the criteria in the past starting from DateTimeOffset.Now,
• in the case where dateTimeOffset.Add#### would decrease the criteria under 01/01/0001 it is instead set to DateTimeOffset.MinValue +1 ms,
• the operator is inverted (> becomes < and vice versa) to match stable behavior (meaning that played<30 shows the beatmaps played during the last 30 days so with a BeatmapInfo.LastPlayed > DateTimeOffset.Now - 30 days) .

If a beatmap does not have a LastPlayed date it is set to DateTimeOffset.MinValue in order to always be shown for played>## and always hidden for played<## (as in stable).

Notes:

• could remove decimal for years, months and other or maybe have some constraint on them like in tryUpdateLengthRange,
• could add some kind of leniency like in tryUpdateLengthRange if deemed useful/needed,
• could add any other date in BeatmapInfo to search filter like LastUpdated, DateAdded and so on,
• could add another type of date search filter so that played=2015y shows the beatmaps lastplayed in 2015.

[bdach]

Does anyone really want or need decimal months/years? Those are possibly the least intuitive units under the sun.

[Elvendir]

I agree with it being not intuitive (except maybe 0.5y). However, as the other units (d, h, m, s) accepts decimals it is to not make the search fail if decimal is used in y or M. I think it does not hurt the player if enabled.

[bdach]

It may not hurt the player but it complicates implementation for little reason. I still say remove it.

[bdach]

I was gonna remove this myself but then saw other places already support decimal so decided not to bother in the end.

[Susko3]

Please try to pull the latest master when submitting a PR, and not have it based on a month old commit.

[Susko3]

Strictly speaking, the reverse of Greater is LessOrEqual. Same goes for the rest.

[Susko3]

This is very misleading. There is no inverse of the equals operator defined, so this should probably throw. (Also the default branch doesn't make much sense).

Function could be renamed to reverseInequalityOperator() to match this.

[Elvendir]

I renamed function as proposed because the previous name was indeed misleading. I also changed the default case to be an out of range exception for unsupported operators.

[Elvendir]

@Susko3 Sorry, I don' t know when it is best to pull master. How often should master be pulled ? Should I do it now ?

[brandondong]

As suggested in #25885 (comment), the changes I made in #25885 are now review suggestion diff's in this PR.

[bdach]

Since this is a relatively recurrent feature request and the code was mostly there I've done a pass on it so that we can get it into users' hands.