Normalise codebase with PHP 5.6 features

[lcobucci]

Sorry for the HUGE pr here but IMO we need to do that so our contributors can have a better source for their tests (and we don't need to ask for these kind of stuff over and over again).

[Majkl578]

Hmm, I'd really like to see generators in action, especially in hydrators etc... 😉

[dennisdegreef]

Generators have the disadvantage of not being compatible with array_map and such (unfortunatly). Would love to see that if they would. They are there for not backwards compatible with arrays.

[Ocramius]

Patch seems good, but I'm reluctant to merge it due to all the merge conflicts it will cause. Also, develop is due a rebase again, and this will make it quite terrible...

[lcobucci]

@Ocramius I can work on the rebase on a different branch before the merge just to do a dry run

[Ocramius]

@lcobucci it would also be fine to merge this only into develop.

[lcobucci]

@Ocramius I'll come with some suggestions after I get home 😉

[Majkl578]

Well, develop is 7.0+, how about also adding i.e. scalar typehints then?

[Ocramius]

@Majkl578 can be done, but needs accurate migration documentation with every signature modification

[Majkl578]

@Ocramius Of course, the real pain would be return types in interfaces I guess because of their variance (parameters are fine in terms of migration).
After migrating a code from 7.0 to 7.1, I still feel like it should be 7.1 or nothing though, since the type declarations in 7.0 are half-baked and nullables & void make a huge difference...

[greg0ire]

If these modifications were done with some kind of script (php-cs-fixer?), wouldn't using git filter-branch the-script on develop prior to rebasing it make the rebase easy?

[lcobucci]

@Ocramius I've started to rebase develop (without these changes) and even with some broken tests I'm almost done. but the tests are broken functional tests are broken and we have conflicts when git tries to apply the very first commit. I'd say that, despite of this patch, we must first solve the test suite, organise the commits and then think about syncing with master.

I've created this PR to have a better baseline for contributing to the ORM. My idea was to have it on master because we have a long journey to achieve v3 and a lot of people will still create new test cases copying things we have.

I understand that it's a freaking huge amount of changes but I think that it needed to be done in order to keep our code standardised (as much as possible).

[lcobucci]

@Ocramius we have develop synced with master on develop-synced-2016-12-09 and develop sync with this branch on develop-sync-with-cleanup.

All the conflicts were solved so there should be no concern regarding this now.

Would be good if you and @guilhermeblanco could check and decide about this clean-up 😉.

[Ocramius]

@lcobucci given that the rebase worked, this can be merged, thanks!

[Ocramius]

@lcobucci I force-pushed develop with develop-sync-with-cleanup (23e6967)