Untangling scheduling/force scheduling from user

As with publishing, this separates out the methods for scheduling and
force publishing. In doing so, it introduces some duplication, but
this is acceptable given the improved clarity and ability to pull
things apart when we move on to extracting the workflow service
objects.

It also introduces some new predicate methods for checking if a given
action can be performed on an edition. Up to now, we've relied solely
on the state-machine provided `is_TRANSITIONABLE?` methods to do this,
but now we need more sophisticated checks than just if the transition
is valid so we can determine if the workflow buttons should be
displayed to the use. This does introduce a bit of a weird overlap
between the `schedulable?` predicate check and the
`reason_to_prevent_scheduling` methods as they both perform slightly
different functions: the former determines if the action can be
attempted by the user; whilst the later does a more thorough check and
returns a reason for preventing the action from being performed. I'm
confident that this weird overlap can be ironed out when extracting
the service objects and think we can live with this weirdness for now.

Not that unlike for publishing where I extracted separate actions for
publishing and force publishing, I've not done so here for scheduling
and force scheduling as, unlike for publishig, there is very little
difference between the two actions. It may be that they need
separating out when we move to service objects, but that decision can
be deferred until then.