Housekeeping part two

[im-denisenko]

This PR is a next step after #751. @XWB forgot about /test/ directory.

I add php-cs-fixer to require-dev section of composer.json, and create a config file for that tool.
Config uses symfony level as default and 3 fixers from contrib.
Now anyone can run ./vendor/bin/php-cs-fixer fix from the root of git repo and get properly defined result.

Also I suggest to enable short_array_syntax fixer from contrib level: short syntax already used in elastica, and now old style and new style mixed together. I did not do this because it's a big change.
If you ok with that, let me know, I will add one more commit, which will convert all arrays to new syntax.

[ruflin]

My question for the old style is: In case we use the old style everywhere, will Elastica still run with PHP 5.3? PHP 5.3 still seems to be the most popular version: http://w3techs.com/technologies/details/pl-php/5/all

[im-denisenko]

It can, but in that case 5.3 must be added back to travis.yml, new arrays must be converted back, and guzzle must be removed from dependencies. And yeah, "We again support 5.3" record must be added to changes.txt :)

PHP 5.3 is a popular version, sure, but it's dead since august of 2014. Users of php 5.3 still can use elastica 1.4.2, which was released just a week ago. Also, more libraries will abandon 5.3 => faster 5.3 will finally die.

[merk]

I am against bumping the required PHP version just to use short array syntax. If thats the only reason for the bump there is no point.

If bumping to access other features to have tidier and better maintained code then it makes sense to do so.

[ruflin]

What I suggest is that we add PHP 5.3 to the build, but don't mark it as required (as we did before). I would not change the communication about the compatibility. It is still 5.4+, but it can work with 5.3. So as long as it is not an extra effort, we keep it compatible with PHP 5.3, but it can be that some of the features don't work.

@merk @im-denisenko What do you think?

[merk]

If short array syntax is used in the codebase there is no point.

If you're bumping required versions why not bump it to 5.5? Though I'd prefer to see the library bump to v2 and start following semver than dropping PHP support.

[im-denisenko]

I think we must either provide full support for 5.3 or not support 5.3 at all, because only real difference between php versions for elastica right now is a new syntax sugar which will throw fatal errors in 5.3.

// cc @jdeniau who "take the responsability of removing the 5.3 support" in #738(comment)

[jdeniau]

I agree totally with @im-denisenko , event debian packages in 5.4 now, but understand the point of @ruflin
As said it is quite easy to restore 5.3 support. I think there is only one reference to short array syntax in the code.

If everyone is OK for re-adding 5.3 support I'll make a PR next week.

[ruflin]

@jdeniau I suggest we try to readd it by removing the array syntax. Perhaps we realise then that with the recent refactoring also some other new "things" got introduced. Would be nice to discuss it directly with a pull request to see the potential issues.