use unit of work while instanciating job objects

## Use Unit of Work While Instantiating Job Objects
    
This fixes an issue where we create a job outside of a unit of
work, which uses an old (possibly closed) connection.
    
Also updated jobs to no longer require a unit of work to be
passed into the constructor, rather the superclass is injected.
Anywhere we manually instantiate (non-guice) jobs, we're
already inside of a unit of work, so the step is skipped.

## Reproducing the Issue from Stage
The issue from stage can be reproduced by setting short timeouts.  This doesn't change behavior, we just don't need to wait 8 hours (the default mysql timeout) to verify the issue.

/etc/my.cnf
```
[mysqld]
wait-timeout=10
interactive-timeout=10
```

And set shorter timeouts for c3p0
/etc/candlepin/candlepin.conf
```
jpa.config.hibernate.c3p0.timeout=8
jpa.config.hibernate.c3p0.idle_test_period=8
```
* with timeouts below 1 minute, you should use the in-memory quartz database.  It doesn't use c3p0 by default, and causes tracebacks when connections die quickly.

After restarting mysql and tomcat, running a refresh pools for an owner (more than **timeout** seconds after the first one is run) will cause a stack trace.