feat: Add the @room feature

[ZhangHanDong]

Increase the @room in the mention user list. Fixed issue #456

[kevinaboos]

Thanks!

This PR has a lot more code changes than I expected to see, which indicates to me that the design is overly complicated.

In general, I don't think the EditingPane, RoomScreen, RoomInputBar, and the MentionableTextInput all need to be aware of changes to the room user list, room power levels, and other stuff.
That's just way too much duplication of state.... and these states aren't small, they could be massive lists.

---

There is also a lot of duplication in how we are updating states in widgets. For example, to update power levels, you tend to both emit an action and directly call a method that sets power levels. We only need to do one of those, and the action approach is better because each widget can handle it independently.

---

Speaking of too many actions, I actually don't see any reason why MentionableTextInputAction is necessary at all.

1. The docs say "Actions emitted by the MentionableTextInput component", but that seems to be backwards. Most of those actions are emitted by other widgets, and consumed by the MentionableTextInput widget.
2. None of them seem to be actually required for correct operation?

---

Finally, there are too many Matrix-level requests being made, which are mostly redundant with each other. It seems like every widget listed above (EditingPane, RoomScreen, RoomInputBar, MentionableTextInput) are all making new requests to get the room members and the room power levels upon every time they are opened. That gets expensive very fast, not to mention is a huge bandwidth (and energy) cost.

Instead, we only need to make those requests once when the room screen is opened, and then each widget can handle any actions that update those lists as they are received from the backend.
EDIT: this is wrong, we do need to make the request to get the latest full user list every time a MentionableTextInput widget is shown, but not all of the above 4 widgets need to make the same request individually. I think your room user list subscriber should make that easy, though.

[ZhangHanDong]

@kevinaboos

Based on your suggestions, I've refactored the code for these components:

1. Eliminated duplicate matrix requests and redundant code.
2. Centralized state management in mentionable_text_input, while room_input_bar and editing_pane no longer store or process any state, resulting in better consistency.

[kevinaboos]

very nice, looks much better! I like the reduction in complexity of the RoomInputBar and other widgets.

I left a few comments about memory efficiency and looking for @room strings.

[kevinaboos]

while this technically works, I think it'll produce a lot of false positives. For example, if someone just typed "`@room`" without selecting the actual room mention from the pop-up users list, they probably don't want to trigger a room mention. (For example, if someone is quoting a message that had @room in it, the text of their new message will indeed contain "@room" but shouldn't be treated as a real mention.)

I think what we actually want to do is to change the get_real_mentions_in_*_text() functions to return a Mentions struct. This would also require adding a field like possible_room_mention: bool to the MentionableTextInput (alongside the existing possible_mentions field).