Issue title: Sonos: player state undefined due to state TRANSITIONING
 Issue body: It looks like Sonos stopped to send the state PLAYING after the state TRANSITIONING in certain conditions.
I can reproduce that when switching to the next song of my Spotify playlist with the Sonos application. The result is that the player controls are unset due to the state value TRANSITIONING.
By the way, I think we should consider TRANSITIONING as PLAYING for the player and enable the play button.
 Comments: 
 Comment 0: It has probably changed with a recent update of the Sonos.
 Comment 1: That is really strange, maybe we are now loosing events !!!

@kaikreuzer : did you update the JUPnP library during the last weeks ?
 Comment 2: I tried to reproduce the problem in my dev environment (Eclipse) and I was not able. I can confirm that **Sonos still sends all expected notifications**.
I think the problem could be a timing problem. The Sonos is sending 2 notifications in the current case, a first with TransportState TRANSITIONING and a second with TransportState PLAYING. As a result, the binding is requesting the change of the channel state first to TRANSITIONING and then to PLAYING. @kaikreuzer @maggu2810 : **does the ESH framework garantee that the channel changes are handled in the order of their requests ?** If they are handled in the wrong order (PLAYING and then TRANSITIONING), it could lead to the result I noted on my RPI2.
 Comment 3: As a workaround, we could decide to ignore all notifications with TransportState=TRANSITIONING but this will require lots of tests to be sure that there is no negative impact. The result will be that the channels are updated later (when receiving the notification with TransportState=PLAYING.

By the way, I am very interested to know if the server is always handling the channel changes in the order of the change requests.
 Comment 4: > @kaikreuzer @maggu2810 : does the ESH framework garantee that the channel changes are handled in the order of their requests ?

We (at least me) need to check that, but I would expect if a channel updates it states from 1 to 2 to 3 to 4 that the linked items are updated in order and there isn't any non deterministic behavior.
 Comment 5: > did you update the JUPnP library during the last weeks ?

No, no changes were done on it.
 Comment 6: Ok thank you for your feedbacks.
In this case, the behaviour I am seeing in my production env is very very strange.
 Comment 7: After adding logs, I can see that when the problem occurs, the binding is requesting two changes of the same channel in a very short sequence (less than 90 ms). The first is requesting the change from PLAYING to TRANSITIONING and the second from TRANSITIONING to PLAYING. It looks like the second change is just ignored because the first change is taken into account by the server too late, after the second change is requested.
**It looks to me like a serious bug in the framework.**
```
18:56:29.769 [INFO ] [s.internal.handler.ZonePlayerHandler] - updateChannel STATE TRANSITIONING

18:56:29.855 [INFO ] [s.internal.handler.ZonePlayerHandler] - updateChannel STATE PLAYING

18:56:29.961 [vent.ItemStateChangedEvent] - SonosChambreState changed from PLAYING to TRANSITIONING
```

Maybe on a fast machine, the server is updating the channel faster and I don't have this problem.

In practice, Sonos is certainly not sending 2 notifications in a so short frame but in fact the handling of the first notification by the binding takes time due to the download of the album art.

As a first workaround, I will handle the album art channel after all other channels. I hope it should help.
 Comment 8: I fixed the Sonos binding issue by updating the covert art channel in a separate thread.

For the framework bug, I am opening a separate issue.
 Comment 9: Not directly related to your issue, but when did we actually introduce a state TRANSITIONING? Its name already suggests that it is not a johnsonanthony@example.net...
 Comment 10: We ? It is a Sonos state.
{'source': 'GithubIssues', 'repo_name_with_owner': 'eclipse/smarthome', 'issue_id': 267396350, 'repo_stars': 952.0}