Sliding Sync: `RoomResult.avatar` won't report an avatar being removed

### Description

Currently, sliding sync will only return an `avatar` value for a room if the sync was an initial one or if the avatar was changed (and not null).

This gives us no easy way to check an avatar has been removed other than adding `m.room.avatar` to the required state, which would add a probably unnecessary overhead to responses and duplicate the value in case the avatar exists.

I'm not sure if this was done on purpose or it's just a side effect of the JSON serialization assuming a null value means the field shouldn't be added. Admittedly, it can be hard to distinguish between a 'this is null because there were no changes' and 'this is null because it just changed to that' values.

### Steps to reproduce

- Remove an avatar from a room.
- Observe the next sliding sync response contains the new `m.room.avatar` event in the timeline but no `avatar` value.

### Homeserver

matrix.org

### Synapse Version

1.133.0rc1

### Installation Method

Docker (matrixdotorg/synapse)

### Database

Not sure, probably doesn't apply

### Workers

I don't know

### Platform

Whatever matrix.org uses.

### Configuration

_No response_

### Relevant log output

```shell
I don't have any from the server, but the sliding sync response after removing an avatar in my case is:

"!ZfTsEBEUwriiEPSJGY:matrix.org": {
"notification_count": 0,
"highlight_count": 0,
"timeline": [
{
"content": {
"url": null
},
"origin_server_ts": 1750937610048,
"sender": "@jorgem_test:matrix.org",
"state_key": "",
"type": "m.room.avatar",
"unsigned": {
"replaces_state": "$Kbso6r9Zoa6egoC0njVuBOV8iCVI2CAq8sUtM6iysj8",
"prev_content": {
"url": "mxc://matrix.org/RSybBEpFiNToNXHVnxCiWXUL"
},
"prev_sender": "@jorgem_test:matrix.org",
"membership": "join",
"age": 1762
},
"event_id": "$oQpCG5Pof4dx3KzgAdsiiy9kcW99B9A2-IQ6i_Nwmh8"
}
],
"limited": false,
"prev_batch": "s6022399461_757284974_215780_3757974183_4245471273_266005404_1502095329_11151677813_0_502149",
"num_live": 1
}
```

### Anything else that would be useful to know?

This issue causes the following Rust SDK issue in turn: https://github.com/matrix-org/matrix-rust-sdk/issues/5285