BREAKING CHANGE.
Scope each "getAvatarUrl" to be instance methods on the entity it
relates to (Room and RoomMember respectively). By doing this, we
can actually pull out specific state such as the `m.room.avatar`
event more easily rather than keeping it in the global cesspit
of `MatrixClient`.
This was complicated by `getHttpUriForMxc` and `getIdenticonUri`
which were attached to the HTTP API to pull out the `baseUrl` when
crafting the URL. Pull out this dependency out and explicitly pass
it in when crafting the URL. This is trivial to get from
`MatrixClient.getHomeserverUrl()`.
Add polyfills for Array.map/filter according to MDN because it looks much
better than the utils format.
Add stub tests for edge cases and implement test for the common case.
The RoomState needs to be current before higher-level processing as this
processing may depend on the end state rather than the progressive state
(e.g. disambiguating BOTH RoomMember's display names).
New sentinels are only created when the RoomMember state changes, so we don't
needlessly deep copy RoomMembers f.e. MatrixEvent. Sentinels co-exist with
RoomState.members which are single instances to which listeners can be attached.
This gets the best of both worlds (don't have to keep re-attaching listeners on
member changes, don't have needless memory consumption).
Accessed via MatrixEvent.sender property. Deep copy the list of state events
from initial sync for old/current RoomState so updating the .sender property
doesn't affect both of them. Reverse the insertion of initial sync MatrixEvents
so state diverges to *earlier* points in time. Add a 'forwardLooking' property
to MatrixEvent to determine which out of 'content' and 'prev_content' entities
should take into account e.g. when determining display names. Finally, always
create new RoomMembers when they are updated in order to prevent corrupting
(read: sharing the same member object) the MatrixEvent.sender property of
existing events in the timeline.
