https://community.openproject.org/work_packages/40437

…0437-easy-emoji-reactions,-eg-thumbs-up-on-activity-entries

…e/40437-emoji-reactions-to-work-package-comments

…e/40437-emoji-reactions-to-work-package-comments

…e/40437-emoji-reactions-to-work-package-comments

…e/40437-emoji-reactions-to-work-package-comments

…e/40437-emoji-reactions-to-work-package-comments

…e/40437-emoji-reactions-to-work-package-comments

…e/40437-emoji-reactions-to-work-package-comments

…s not reacted as requested by @psatyal

…e/40437-emoji-reactions-to-work-package-comments

Users who do not have commenting permissions: typically the `add_work_package_notes` and anonymous
users cannot add new reactions but they can view any existing reactions. Futher, the "Add reactions" button
is also hidden from them.

In view only state, the emoji reactions render as primer invisible buttons in disabled state.

> They can respond to user input and provide feedback, but it does not trigger any actions.
> See: https://primer.style/components/button#inactive

The view only reactions mimic primer inactive buttons but without the muted styling and cursor change

…-comments

…-comments

UTF-8 is widely adopted and the default format for Postgres; storing emoji's in unicode format is then possible
and should be searchable as any other string- and leveragable via AR named enums.

Whilst we could also store integer numbered enums, it would introduce additional overhead that seems unnecessary

Avoid possible collation issues in uncode formats- storing reactions allows us to read the emojis from relevant stores at runtime

 * ARIA-label, show names and emoji type: "{Name of reaction} by {user A}, {user B} and {user C}".
 * Visually, show just names: "{user A}, {user B} and {user C}"

… avoid n+1 calls on journals

Pass it down the component chain. TODO: reduce allocation bloat by extracting it to a lazy memoized helper