Test on Travis always high and low deps

[goetas]

• before this PR, dependencies of this project were uncertain. this tries to make more clarity on what are the minimum requirements for the serializer
• added code coverage on scrutinizer
• performance improvements

[stof]

it would be much better to run a single job for prefer-lowest instead of one per PHP version, to limit the size of the build matrix. Travis allows only 5 concurrent jobs per repo owner (i.e. for all repos of @schmittjoh in this case) so the size of the matrix has an impact

[goetas]

i tried to to optimize things to lower the build time and now is almost half time.
do you know some projects using the approach you suggested? to see exactly what do you mean

[stof]

see https://github.com/minkphp/Mink/blob/master/.travis.yml for instance

[goetas]

done

[schmittjoh]

I'm really not sure about this approach. Previously with the lock file, we have a stable build and if we update the lock, and something breaks we know which dependencies to look at.

Without the lock file, things might break without us changing the code. People will complain about tests already being broken when opening pull-requests and we end up hunting down where it comes from without knowing for which dependencies the tests worked. This highest lowest seems useful before a release, but also very fragile otherwise.

Can we combine both approaches (lock file for normal usage, highest-lowest before a release)?

[goetas]

Without the lock file, things might break without us changing the code.

personally i prefer to do not commit lock file. Not committing it allows to understand if the declared dependencies and requirements allows to work correctly with the serializer. if some external dependency broke the serializer, the serializer should declare to be conflicting with that version.
committing the lock file ensure that the dependencies at that point in time were ok, but says nothing about the dependencies of the serializer.
A good point about this is #578 (comment) and composer/composer#2461

[stof]

@schmittjoh with the previous lock file, you were testing the library only against dependencies that none of your user would use as you were locking versions unmaintained since more than 2 years. so this was making the testsuite useless (as it would not ensure that things work in a real project) rather than making them fragile.