Use the new build env on Travis

faster vms, more ram, more cpu, faster boot times,

docs coming soon
cat an error log if it fails
Merge pull request #539 from joshk/patch-1

Use the new build env on Travis
only chmod if pid file is owned by current user

I ran into the same issue that #497 was trying to fix, but I don't think
the merged solution will work. The problem is that the old pid file is
owned by the previous user(abc123 in #497) and thus, the file cannot be
removed by the new user (xyz789). A solution is to check if the current
user owns the file and only performs the chmod if that is the case.

Squashed commit of the following:

commit 80acee57966998fe0781f4a3263440e6a2c21bef
Author: Sajan Alexander <sajana@spiceworks.com>
Date:   Mon Nov 24 09:33:01 2014 -0600

    use uid, not gid

commit 1c954afdc452df57c282a19377ce13e26930d9c8
Author: Sajan Alexander <sajana@spiceworks.com>
Date:   Sun Nov 23 17:11:59 2014 -0600

    remove removal of pid file since permission error still exists

commit f5cb7a8a113d43d4ae0050fa4380c90db243b45b
Author: Sajan Alexander <sajana@spiceworks.com>
Date:   Sun Nov 23 16:47:26 2014 -0600

    make sure existing pid file is owned by the current user
Merge pull request #544 from spiceworks/master

Removal of pid file can cause error
Allows complete functions to be computed in parallel during scheduling

I've noticed that most of the time spent during scheduling is spend computing
complete functions, as these can involve various kinds of expensive checks
against remote file systems and services. This modifies the add function in
worker to allow complete functions to be computed asynchronously while
traversing the dependency graph. This can result in significant savings,
lowering the time needed for my twice-hourly scheduling from about 9 minutes to
about 3.5 minutes.

In order to gain the full benefit, I added an attribute ignored_root to Task.
If true, the task will not be directly scheduled when run as the root task from
the command line. This allows for scheduling many tasks via a WrapperTask
without actually scheduling the WrapperTask. Thus, we don't need to compute the
expensive complete() function of the WrapperTask on a single processor.

Using multiprocess requires picklable tasks, and this is incompatible with many
of the unit tests in worker_test. In order to get around this issue and allow
maximum compatibility with client code, multiprocess is not used at all unless
enabled via the command line or client.cfg. In order to minimize the code
difference between these cases, I added wrapper objects simulating the necessary
pool and queue interfaces for the single-processor case. This also allows the
existing unit tests to test most of the new code path, and I've only had to
write a few new unit tests to exercise the multiprocessing code.