1098734 - Fixes known celerybeat startup issues

https://bugzilla.redhat.com/show_bug.cgi?id=1098734

The root cause of this bug is that celerybeat is not starting and running as expected. See the BZ comments for more info on this relationship.

This commit comes with tests, and they all pass for me with ./run-tests.py

I also smoke tested the schedules by manually ensuring scheduled sync's run using a command similar to the one at [the end of this section](http://pulp-rpm-user-guide.readthedocs.org/en/latest/recipes.html#mirror-a-remote-repository).

This commit changes two things:

1)  It reworks the upstart init scripts and systemd unit files to not specify the celery app using -A or --app, but instead use --schedule to specify the scheduler class directly, and not specify the app. The scheduler is aware of the app, it ends up being equivalent. By doing this, the file pulp.server.initialization is never imported, which is important because importing pulp.server.initialization causes mongo to initialize. pymongo is not fork safe, so initializing pymongo prior to celerybeat forking is the root cause of the bug. It also reworks the logging to work with this new method.

2)  It also adjusts the get behavior of the schedule property on the Schedule class to properly use the superclass. I believe this is a more correct behavior given what I know about the base class and our derived object.