Update Guzzle to next release (3.5.0)
Fix detection of event listener in tests

Previously we were expecting to have the only event listener, but newer
versions of Guzzle use the hooks too. So we can't assume that any more.
Update Guzzle to next minor release (3.6.0)
Implement ArrayAccess for EmbeddedCommand

Since Guzzle 3.6.0, all commands must implement ArrayAccess and
ToArrayInterface. Internal Guzzle commands extend from Collection in
order to implement the array interfaces, so I'm copying that approach
here. I'm doubting that EmbeddedCommand objects will need to be
enumerated as arrays.
Update subclassed method signature

Guzzle\Service\Command\OperationResponseParser had the method signature
changed in Guzzle v3.6. It seems like a change that doesn't affect
desk-php, just needs to update the method signature in anything that
subclasses it.
Update ModelBuilder header copying

Guzzle changed the expected format for headers to be passed when
creating a new Response object. This commit updates the ModelBuilder to
support this new format. A HeaderCollection can't be passed in, it must
be a Collection or an array.
Update Guzzle to next minor release (3.7.0)
Sort associative arrays before comparing in tests
Update Guzzle to next minor release (3.8.0)
Use actual booleans in desk.json

There was a mixture of values, some boolean and some as strings (e.g.
"true"). These need to be actual boolean values, not strings.
Allow any 3.7 or 3.8 version of Guzzle

This is the same requirement as what the AWS SDK for PHP uses. It's a
bit like using the pessimistic version operator, but allowing both
"~3.7.0" and "~3.8.0".

This will need to be revisited when Guzzle 3.9 is released. VersionEye
should notify me when that happens.
Pin php-coveralls to specific commit

VersionEye will notify me if a new version is available. Then I can
decide if I want it or not. dev-master could be dangerous.
Pin Mockery to a specific commit

This will help move to a tagged Mockery release.
Remove composer.lock from version control

Committing `composer.lock` to version control can "help your team to
always test against the same dependency versions". However, new
projects that depend on this library aren't affected by it, and will
merge the requirements in `composer.json` with all others for the
project.

Since this creates more stability for testing, and less stability for
real-world use, it should be adjusted to make the testing environment
more similar to the experience of first-time users, and not have the
luxury of the specific versions in `composer.lock`.