[1.x][Composer] Update dev dependencies to supported versions

[andrerom]

In order to get travis to not run out of memory on php 5: Update dependencies to supported versions, on dev dependencies even pick latests patch versions within all existing supported versions.

Todo:

• Adjust .travis.yml to match composer changes, but wait for more specific versions on very old builds #471 to be merged first

[XWB]

You can also increase the memory limit, like https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/.travis.yml#L35

[andrerom]

True, but as amount of possible releases to resolve grow that might not be enough on PHP5 eventually again.

But that said, if I continue down the path here I'll need to remove tests for older symfony releases, so I realize I need some input from @dbu / @ddeboer / * here on what is preferred.

[dbu]

this fails for all travis builds that are about older versions.

i consider 1.3 of this bundle to be in a mode where we only do very important security fixes but otherwise no updates anymore. if you can change the .travis.yml file so this builds again, thats a help - but i would want to leave composer.json alone. and if it keeps failing, i can live with that too, the 2.* version is whats relevant.

[dbu]

i don't think we should suddenly restrict dependencies of the maintenance version. instead, we can change the versions in the .travis.yml file to only install more specific versions, that usually helps with the out of memory problems.

[andrerom]

Probably safest. Then we can just adjust require-dev, it should be enough to fix it, on top of corresponding travis.yml changes.

[dbu]

ah sorry, the session listener hackery is part of the 1.3 version so thats why you wanted to fix that. i'll try the .travis.yml approach quickly.

[dbu]

#471 was enough. i suggest we drop this.

although i notice that composer.json allows far more versions than we actually test. but whatever, this is legacy code.

[andrerom]

Ok, well you know where to look once the issue comes back then ;)