Issue title: Freezes when switching quality. Chrome errors
 Issue body: @jcague  @lodoyun  [Updated the whole issue with more infos, also provided 2 videos]
**Description**
It happens that when switching from 2 different quality layers, a freeze occurs, sometimes it get stuck for 2/3 seconds and it's very annoying.
At first I thought it may be a network issue but then I deployed everything in a local network environment.

Sometimes, few seconds after switch, it freezes for about 2 to 5 seconds:
When it happens is constantly reproducible.

**Steps to reproduce the issue:**
1. Take 2 pc. open chrome with --enable-logging=stderr
2. One is only publishing (640x480, maxBW: 600, spatialLayer: 2)
3. One is only subscribing. 
4. while subscribing switch to a static res ex. 1,2. wait 10 seconds. the stream freezes? 
* if it freezes, look at the chrome console, you will see tons of:


`
(43320:0) has invalid frame references, dropping frame

(43321:0) has invalid frame references, dropping frame

(43322:0) has invalid frame references, dropping frame
`

* else switch from 1,2 to 0,2 and repeat the observation.
5. If you wasn't able to reproduce reload the publisher. and repeat the test until you find the issue.


**Describe the results you received:**
Randomly (I didn't find the way to reproduce it constantly yet) after the switch it freezes few seconds.

**Describe the results you expected:**
the transitions are smooth, at least in a local network environment.

**Additional information you deem important (e.g. issue happens only occasionally):**
* It's not subscriber related. of you reload the subscriber you will be able to see the freezes again.
* It happens only sometimes and could happens or switching from lower to higher spatial or viceversa.
* It doesn't happen when switching different temporal, only spatial
* sometimes it doesn't happens at all

ex. in this video happens only from lower to higher: 
[YOUTUBE](https://www.youtube.com/watch?v=r9ZrivlEfvM)
also note that in this case for example, it switches correctly from 320x240 to 640x480 and goes well for 2 seconds, then the problem occurs.

and in this only from higher to lower
[YOUTUBE](https://www.youtube.com/watch?v=3wzakEjm2NE)


**Licode commit/release where the issue is happening**
0ce79ce

**Additional environment details (Local, AWS, Docker, etc.):**
tried:
ec2
local environment
2 different network provider and router
 Comments: 
 Comment 0: didn't try to reproduce it yet, but which Chrome/Firefox versions are you using? 
 Comment 1: chrome stable 59.
Now I'll try with newer versions of chrome (beta and dev)
 Comment 2: unfortunately same behavior with chrome 61 dev
 Comment 3: @jcague 
It is only a chrome issue. (tested also with dev 61)
Firefox has no problem decoding the same stream. maybe chrome expects something we don't do?
or maybe it's only a bug but I don't think so since hangouts uses simulcast for each multi party conference :/
 Comment 4: My guess is that our simulcast implementation is not fully complete and thus we have some issues supporting latest versions of Chrome, where pictureId (a field inside VP8 payload) is more relevant apparently. Maybe there's something else so we'll check it in the next days/weeks and will work on a solution. We also need to fix it sooner rather than later.
 Comment 5: So, testing various version seems that chrome 58 broke the mechanism.
I also found some other people having similar issue (related to pictureid, not the same error however.

here's the link:
[MONORAIL](https://bugs.chromium.org/p/chromium/issues/detail?id=732032)
 Comment 6: I can't reproduce it. 
@kekkokk can you check if it freezes just because:
1. the publisher doesn't send the higher spatial layer and you force to use it.
1. the subscriber sends a remb lower than the lower quality and Erizo enables slideshow mode.
 Comment 7: 1. no
2. no

I said this because I'm in local network and I keep open two version of chrome (subscribers), one 57 and one 58. the 57 always switch with no problem at all (also firefox). the version of publisher doesn't matter
Only chrome >= 58 cause problems.

If you can't reproduce try to reload the publisher page and repeat the step 4 on the original post. It doesn't happens every time

i'll make you a proof video in a minute

 Comment 8: interesting, can you send a screenshot with the subscriber's stats graphs for video (taken from webrtc-internals) and from the quality_layers graph please?
 Comment 9: sure, meanwhile:
[YOUTUBE](https://youtu.be/cxEmYsW6ux8)
 Comment 10: In this test I let him growing until max layer (1,2) then i switched to (0,0) then switched to (1,0)

from 0,0 to 1,0 it froze.

these are the screens you requested

![screen shot 2017-07-11 at 16 48 35](https://user-images.githubusercontent.com/15072723/28074432-d884a8a2-6658-11e7-959c-8568b99d8612.png)
![screen shot 2017-07-11 at 16 48 21](https://user-images.githubusercontent.com/15072723/28074433-d9c56af8-6658-11e7-8fbc-8b086d8ff6a4.png)

 Comment 11: the graphs show the expected behaviour, so it's Chrome which drops all frames as you stated before. I'd say it's because of the new pictureId mechanism we need to implement to be fully compatible with Chrome again (https://bugs.chromium.org/p/webrtc/issues/detail?id=7897). According to this bug, Chrome drops all frames that doesn't continue with the previous pictureIds. We don't take that into account, so we should implement it too. 
@lodoyun I wonder if we need also to handle pictureIds in slideshow mode with vp8 too.
 Comment 12: thanks for keeping me informed about your finds.
I was also reading all related "bug" in chrome 
[Monorail](https://bugs.chromium.org/p/webrtc/issues/list?can=1&q=pictureid)

Do you think it would be a simple and fast fix?
Also, it's very sad that they didn't announce this breaking mechanism in the 58 webrtc update thread.
 Comment 13: I double checked the graphs you sent and I realize that the framerate decoded is still greater than 0 when it's supposed to be dropping frames... that is a bit weird.
 Comment 14: I think you are wrong, actually at second 48 (the first graph), when the 5 seconds temporary freezes occurs, the framesdecoded don't grows.
 Comment 15: I see it now. And now I'm able to reproduce. I think it happens more often with higher bitrates. Anyway, I have a WIP branch where I rewrite pictureIds when there's a switch in the spatial layers, and it seems it helps a lot. There is still some case where the video freezes for 3 seconds, but Chrome does seem to complain about frames missing references anymore.

I guess I'll submit a PR this afternoon with the WIP after having run more experiments. 
 Comment 16: can't wait to test and maybe help
 Comment 17: can you try the PR? https://github.com/lynckia/licode/pull/962
 Comment 18: of course! 
are the 3 sec freezes still present in this pr or you addressed also these?
 Comment 19: Based on my experiments it should be reduced, but I could see it happening some times yet.
 Comment 20: WOW!
Butter smooth on transitions, only a micro stuttering time to time (but not during transitions), maybe it's the chrome decoder. 
Firefox seems smoother overall, so maybe it's the different decoder implementation.
Anyway no more error in console, I think the main problem is to consider fixed.

Really appreciated your timing!
 Comment 21: There can be still some cases since the solution I implemented is pretty simple, but I think it's a good trade-off, please feel free to open it again if you experience more cases.
 Comment 22: no problem so far. thanks!
{'source': 'GithubIssues', 'repo_name_with_owner': 'lynckia/licode', 'issue_id': 241209052, 'repo_stars': 2928.0}