Added the ability to disable group similar time entries

[utlark]

What does this PR do?

Adds the ability to disable grouping similar time entries. #445

Checklist (DO NOT REMOVE)

• I read the contributing guide
• I signed the Contributor License Agreement.
• I commented my code, particularly in hard-to-understand areas

[Onatcer]

thanks for the contribution. a few notes:

• The grouping currently only exists in the time view, i think it makes more sense to have the setting there directly. a cog icon ghost button on the right side of resources/js/packages/ui/src/TimeEntry/TimeEntryMassActionRow.vue with a popover and the setting inside should work fine i think. (the goToProfilePage which is duplicated from profile.spec.ts and the profile.spec.ts test can be dropped then)
• there are a few page.waitForTimeout(500) in the tests. are those really necessary, usually you should just wait for the element in playwright because its a lot faster.
• the groupSimilarTimeEntriesSettings useStorage key should not have a "theme-" prefix, should be singular (groupSimilarTimeEntriesSetting) and should be separate from the theme.ts . i don't think any of the existing utils are a good fit, it can just be a timeEntryGrouping.ts.
• the Ternary in TimeEntryGroupedTable is pretty hard to read imo this should be an early return.

[Onatcer]

i just realized the TimeEntryMassActionRow is used in the Reporting as well. We can just add a "settings" slot to the component and only pass it in Time.vue. The useStorage can stay in the main application then and can be passed down like the PR already does.

[utlark]

Alright, I’ll try to move the setting closer to the Time view. I’ll also adjust how storage is handled (key, naming, extracting it into a separate file) and replace the ternary with a more readable early return.

Regarding the tests — without waitForTimeout they either didn’t work at all or behaved inconsistently.

Observations by case:

• On the first call of goToTimeOverview(page), waiting is generally not required.
• When calling createEmptyTimeEntry(page) twice, the timer for the second entry does not stop and keeps running. The added wait ensures that the entry is reliably created and stabilized.
• After the second goToTimeOverview(page), the page opens but the data is not fully loaded yet, while the test already starts searching for page.locator('[data-testid="time_entry_row"]'), which results in the element not being found and the test failing.

I agree that waiting by timeout is more of a workaround, but I was not able to find a stable alternative based on waiting for specific states. I’m not very familiar with writing Playwright tests, so I might be missing a better approach here.