Support per-room displaynames

[KitsuneRal]

As per matrix-org/matrix-doc#545 discussion, the API is already in place (although Synapse discards all custom-made displaynames when a generic displayname is changed). libqmatrixclient allows to send arbitrary m.room.member events nowadays; but it only stores a single common displayname and will be confused by such events arriving over the wire. There's a need of a RoomMemberTraits structure that will store this room-specific displayname (and avatarurl, which also can be overridden per-room). The considered options in how to manage these structures are below; option 3 looks most reasonable:

1. Aligned with the API, which means that in addition to storing a User* in Room, we store a RoomMemberTraits instance for each m.room.member event coming. We'll have to make lots of such structures, and most of them will have the same traits for a particular user. And Qt's COW won't help because these events will be parsed separately. But that's really easy to implement. Updating the current user displayname/avatar logic is also fairly straightforward.
2. Optimised basing on the generic traits stored in the user profile. The number of structures will drastically decrease (because very few actually make use of this feature) but the logic is more complex. First of all, once a User object is created, we'll have to request its profile from the server (trying to not overload the server with such requests along the way - imagine getting profiles for 10k+ users of Matrix HQ at initial sync). Upon m.room.member arrival, we'll have to check whether the displayname/avatarurl there coincide with the generic ones; if they don't, create RoomMemberTraits and store them for this user and room (either in Room or in User, there's no preference).
3. Optimised basing on deduplicating effort. Again, we use the fact that very few are actually using room-specific names and avatars, but instead of using generic traits as a fallback we store all variants of the user traits we've seen in User. At m.room.member arrival, simply check whether this User already has an exactly the same RoomMemberTraits for other rooms; if yes, reuse the existing traits and add the room of this member event to the rooms list associated with this RoomMemberTraits; if no, add a new RoomMemberTraits. Generic traits of a User will have to be separately retrieved upon explicit demand.

[KitsuneRal]

After the first attempt to code:

• RoomMemberTraits are actually not a thing; only a specific name, or only an avatar, may be overridden. Besides, RoomMemberTraits are very clumsy to index for Option 3; strings for names and urls for avatars are much better for that. So it's better to treat each trait separately.
• Option 3 makes retrieval of user traits in a room context a linear search along available options (Room pointers can be stored into hashed sets but we still have to roll through all available, e.g., names). In case of human users this number will obviously be low; however, bots (those very few that do use this feature) are likely to have a room-specific name for each room they are in. So if I as a local user have 1500 rooms (referring to Matthew's roomlist), and some bot happens to be in the majority of them, there are 1000+ different entries in the traits list. It's still not too much (maybe several ms) if a room-specific name is retrieved, say, once a second (note that this name is mostly for displaying purposes).

[KitsuneRal]

It's worthwhile to finally think what use-cases we have to support. I'm using display names below; per-room avatars are an even less frequent case.

1. A human user. Relatively few (assume ~10) names and relatively few (assume ~20) rooms with name overrides; a sub-case with a single alter-name used in all the 20 rooms. Option 3 works very well for the case.
   a. A human user with a scripting engine. The number of rooms increases to ~500, the number of different names can also increase. The worst case since we have to support both coarse-grained (500 rooms) and fine-grained (per-room) name overriding.
2. A bot. The number of names is equal to the number of rooms accessible by the local user (~1500). Option 1 is the best for the case but Option 3 is still not that bad (see the previous comment).

Overall, the whole thing is not widespread (especially because Synapse flushes all overrides when a profile name is set) so postponing it for now.