srm: simply job.setState

There are currently two setState methods in Job.  The two-arg version calls the 3-arg
version will the 'save' argument hard-coded to true.  The 'save' argument provides
some control over whether the updated job is saved to some JobStorage.

Currently, all calls to setState use the 2-arg version (with 'save' as true),
except for Scheduler, which explicitly calls job.saveJob, so has the same
effect as calling the 2-arg version.

This patch simplifies the process by removing the 3-arg signature method
and always calling the zero-arg saveJob method.

Target: master
Patch: http://rb.dcache.org/r/6651/
Acked-by: Gerd Behrmann
Acked-by: Dmitry Litvintsev
srm: remove stateChanged method

Current srm code has a kind of call-back method within Job to notify subclasses that the
job's state has changed.  While there are some benefits to this approach, it also
makes the code unnecesarilly complicated, as the subclasses can override the
setStatus method to discover when the status has changed.

This patch changes the code from using the stateChanged notification to overriding
the setState method.

There are two side-effects of this patch.  First, calling setState with the Job's
current state is now an error (previously it was silently ignored).  Second, the
order in which the subclass hierarchy is traversed is reversed.

There were a few places where the code attempts to update a Job's state with its
current state.  These have been fixed with this patch.

The inversion of the order doesn't matter.

Target: master