Update Behat Drupal extension to 3.2.2

So, here's Drupal 7's current support:

Drupal 7: PHP 5.2.5 or higher (5.4 or higher recommended).

From https://www.drupal.org/docs/7/system-requirements/overview

It's always been Panopoly's goal to support the same versions as Drupal 7 and the contrib we include. The reason we run PHP 5.4, is that it's the earliest version we could get to work in the tests. :-) If we could've gotten PHP 5.3 working, I think we probably would've use that (I'm not totally sure PHP 5.2 will run all our contrib?)

Anyway, my worry with doing all our tests on PHP 5.6 or later, is that we might inadvertedly break users on older versions of PHP. And for better or worse, most Drupal 7 sites are going into maintenance mode soon where their servers are likely to not get a lot of attention, as folks work on a new Drupal 8 site on some new server. I've seen this a lot with Drupal 6 sites, and I don't want to make life harder for people in this situation.

Would it be possible to split the matrix so that we run one test (clean install) on PHP 5.4 with the older Behat extension, and all the rest (one on 5.5, full set on 5.6, one each on 7 and HHVM) on the newer Behat extension?

Probably. But if we need to run one build on the old Behat extension, why use the new Behat extension at all?

It'd be good for our Behat code to be compatible with the newer Behat extension, so that child distributions could decide they want to use the newer version and don't care about old PHP. So, I guess that's an argument for running at least one build on the newer Behat so that we can make sure that we are compatible...

Ok, two paragraphs later and I'm now all for this plan! :-) We can still debate which builds should be on which versions, but we should probably test both, and we should also probably at least enable the PHP 7 build, which I thought we had, but I guess not.

Some experimental patches I'm going to use to test on Travis

EDIT: Here's the first Travis build: https://travis-ci.org/panopoly/panopoly/builds/195667996

EDIT: Here's a correct build: https://travis-ci.org/dsnopek/panopoly/builds/195673023

Next experiment!

EDIT: Here's the Travis build: https://travis-ci.org/panopoly/panopoly/builds/195670337

EDIT: Here's a correct build: https://travis-ci.org/dsnopek/panopoly/builds/195672852

It turns out that the version compatibility for drupalextension 3.2.2 is more complicated than just needing PHP 5.5+ -- it actually will work with PHP 5.4, and composer can even install it, but the composer.lock file pins versions of the dependencies that need PHP 5.5+. If you don't have a lock file and run on a PHP 5.4 system, it simply selects older versions of those dependencies that work on PHP 5.4.

So, we have two options:

1. Provide separate composer.lock files for different PHP versions, or
2. Remove the composer.lock file and let composer figure everything out

Option #1 is lower complexity in our build, but it has slower performance and could add instability to the build (if something unexpected changes with the dependencies). Option #2 is more complexity to maintain, but I think I'm leaning to that option for the time-being.

Gah! I couldn't make Option #1 work, even though it's theoretically better. Here's a new set of patches that just removes the composer.lock file

EDIT: Here's a Travis build: https://travis-ci.org/dsnopek/panopoly/builds/195687430

Alright! Here's a patch that gets the PHP 7 and hhvm builds actually running, and actually allowed to fail (which PHP 7 definitely is -- I haven't waited for an hhvm build to completely finish, but I wouldn't be surprised if it's failing too)

Committed!