Ensure no old gems are left behind between test runs.

[benpatterson]

The issue is thus:

1. We run a job on a jenkins-worker that includes a gem upgrade to sass 3.3. This produces deprecation warnings
   ** CC @andy-armstrong on that issue, related to Update SASS ( 3.3.5), Bourbon (4.0.2), Neat (1.6.0) #3462. I'm guessing those deprecation warnings will have to be addressed.
2. Then we run another job on the same jenkins-worker that is using the old gem (say, running on master)
   ** However, in this second run, we still get the deprecation warnings. This is because the previously-upgraded gems are still left behind in the rbenv.

@jzoldak @clytwynec Can you take a look?

[benpatterson]

@jzoldak @clytwynec - builds were failing if it happened to be the first job a given jenkins-worker has ever run. I've made a change that should work on both old and new workers. Please have a look.

[benpatterson]

@jzoldak @clytwynec Here's output from Jenkins now (in this case, the previous build had run a newer version of sass than the current build is using---the last line is bundle clean):

14:32:14 Using rake (10.0.4) 
14:32:14 Using addressable (2.3.5) 
14:32:14 Using sass (3.2.12) 
14:32:14 Using thor (0.18.1) 
14:32:14 Using bourbon (3.1.8) 
14:32:14 Using colorize (0.5.8) 
14:32:14 Using dalli (2.6.4) 
14:32:14 Using ffi (1.9.0) 
14:32:14 Using launchy (2.1.2) 
14:32:14 Using neat (1.4.0) 
14:32:14 Using rb-fsevent (0.9.3) 
14:32:14 Using rb-inotify (0.9.2) 
14:32:14 Using sys-proctable (0.9.3) 
14:32:14 Using bundler (1.3.2) 
14:32:14 Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
14:32:14 Removing sass (3.3.5)

[clytwynec]

Make sense to me. 👍

[jzoldak]

👍