You should not give them sudo access if you need to have accountability and can't easily hold them accountable. Maybe if you lock it down to specifically "sudo service apache2 reload" and let them run that one command with those arguments.
For editing configuration, use acl / filesystem permissions to give them access to write to the specific configuration files they should be changing. Giving them sudo access to an editor means they can edit/modify any file on the system, including sudo itself, or change sudo's configuration so that it doesn't log anything.
If they can install software, they can install malicious software. Don't let them do this, have someone you can hold accountable for the well-being of the system do it.
If they can patch libraries, they can patch core libraries and inject malicious code. Don't let them do this, have someone you can hold accountable for the well-being of the system do it (if it has to be done).
sudo itself can be configured to log every command to syslog, and you can set up syslog to forward log entries to a secured server over the network to keep accountability on the logs.
I would probably not give him sudo access, but configure the system such that he's in a group which can write to the apache configuration files and the webroot.
He'll need a way to tell apache to reload the configuration, so you might look into a ssh-key which isn't allowed to drop to shell, but triggers a service apache2 restart when someone logs in with it. Alternative would be to use a setuid program which takes no inputs and does the apache restart. Or he can just ping you via email or IM when he needs it reloaded.
For installing packages, I'd just have him send you a list and then after glancing over the list, install them. From a security standpoint, someone accountable (you) should be downloading / compiling / patching any libraries that need to be patched.
sudo should already be logging every command to syslog (at least, it does by default in Ubuntu if I remember correctly, might be different in your setup), so you should probably verify that it does regardless, and for added accountability, configure syslog to log to a remote syslog server which can be secured.
If you generally trust the contractor, then there's probably not a whole lot you really have to worry about. But if you have to be able to hold him accountable, then it's necessary to look at this from a "what's the worst he could do with priviledge X?" standpoint.
