Rooms loaded from store don't appear to be firing events into the client

Sync responses containing rooms are converted using `_mapSyncResponseToRoomArray` in the SyncApi, currently. With this, rooms sometimes aren't sent off to `reEmit` to have their events reach the MatrixClient.

Here's the portion of code being mentioned from here on down: https://github.com/matrix-org/matrix-js-sdk/blob/547333c946e57dc618e144c0f8f6c2d84741d54a/src/sync.js#L968-L973

A room is first looked up using the backing store, which may be in memory, web, or something else. If the room is found, it is passed along just fine with `isBrandNewRoom` false. If the room is not found, however, it is created and marked as a new room.

(now referencing createRoom: https://github.com/matrix-org/matrix-js-sdk/blob/547333c946e57dc618e144c0f8f6c2d84741d54a/src/sync.js#L91-L105 )

When the room is created, it is sent off to `reEmit` so the events originating from the room end up also being raised in the client.

Because of `getRoom`'s contract on the store, it can't return null in hopes that the sdk will build a new one for it (especially considering the store may be returning other information that causes the sdk to not update room state, because the room should already have it.

This means that rooms coming out of the store may not re-emit their events to the client, leading to interesting behaviour in various applications using the sdk.

Of course I may have completely missed something that has lead me in the wrong direction. Please point me back to the correct path if I've strayed too far.

Start in src/sync.js at _mapSyncResponseToRoomArray and compare the existing-room path with createRoom and its reEmit call. Trace getRoom's store contract and determine how rooms loaded from the store should still re-emit their events to MatrixClient. Done means stored and newly created rooms consistently deliver their events to the client.

Written by the indexing model from the issue text.