[Feature] O-History

[jpnsfw]

Is your feature request related to a problem? Please describe.
Presently Stash implements O-Counter as a single number for each scene/image. I would like to be able to track the history of "O-Events", i.e., they should be stored as timestamped rows in a new table.

Describe the solution you'd like

• Replace the "o_count" column of scenes/images tables with a new "o_history" table, which has columns "timestamp", "scene_id", "image_id"
• When displaying O-Count elsewhere in the UI, perform a simple query on the o_history table
• Pressing the "O" button adds a new row with the current timestamp
• Decrementing the O-Counter is replaced with removing the most recent event from the o_history table matching that scene/image (and resetting the count removes all)
• Optionally, a UI that displays the O-History

Describe alternatives you've considered
None.

Additional context
The idea is to use Stash for O-Tracking.

[randemgame]

This is similar to a request I have posted here #3392, although I was interested in tracking the play history rather than the O-counter. Honestly, either option would be preferable to what we have now, where only the most recent play date is being saved, and the O-counter is stored as a simple int. The solution presented here sounds good. I'm really confused that there has been so little interest in recording play/O history in Stash, despite it being a basic feature of every other organiser I've used.
The longer it takes for any such history feature to be implemented, the more user history data is being lost to time! I wish this could be acknowledged so that any such history feature, which I have to expect is inevitable, would be more prioritized in the development.

[jpnsfw]

@Herpes3000 - interesting, thanks, maybe both issues could be combined in a single PR. Any thoughts from project maintainers on whether this would be better served by a single table (item_events) vs separate tables (view_events + o_events)?

[WithoutPants]

I think the two features should be separate and stored in separate tables. I don't think we gain much by combining them.