feat(stats): filter (in)active tasks

[acidghost]

Closes #55.

I took the liberty to refactor the interface to getStats so it's a bit cleaner to pass arguments for different situations (i.e. w/ interval or not).

Feel free to change stuff around; you might want to rename some stuff or re-format (I don't like long lines since I sometimes use split panes/windows and line wraps make code less readable IMO, but you're the boss here).

✨ Copilot summary

This pull request introduces a new feature to filter tasks based on their active status in the hours application. The changes span multiple files and add functionality to view active, inactive, or both types of tasks in various reports.

New Feature: Task Active Status Filter

• cmd/root.go: Added flags --active and --inactive to filter tasks based on their active status in the stats command. Updated RenderStats call to include the new filter parameter. [1] [2] [3]
• internal/types/types.go: Introduced TaskActiveStatusFilter type and constants to represent active, inactive, and both task filters. Added methods to check the filter status.
• internal/persistence/queries.go: Modified FetchStats and FetchStatsBetweenTS functions to accept the new filter and apply it in SQL queries. [1] [2]
• internal/ui/stats.go: Updated RenderStats function to use the new filter and refactored to use a statsFetcher struct for fetching stats based on the filter. [1] [2] [3] [4]
• internal/ui/cmds.go, internal/ui/initial.go, internal/ui/log.go, internal/ui/model.go, internal/ui/report.go, internal/ui/update.go: Updated various functions and models to pass and handle the new activeFilter parameter. [1] [2] [3] [4] [5] [6] [7] [8] [9]

These changes collectively add the ability to filter tasks by their active status, enhancing the usability of the hours application by allowing users to focus on specific types of tasks in their reports.

[dhth]

Thanks for the change (and the bias for action 🙌).

I'll take a look at the requirement and the change in the next few days.

[dhth]

Hi! Once again, thanks for sending in the change.

I think adding this feature makes sense. Although, I would prefer to do this via a single flag that accepts a value for the task status to be used for filtering. That way we leave scope for another task status that hasn't been added yet.

I've created a first draft PR with changes that I thought made sense here. Lemme know what you think about it :)