Rework Publishing API scheduling code

This is mainly following on from #1921 to bring the code in line with how unscheduling works by using separate workers for publishing the publish intent and the "coming_soon" item for editions when they are scheduled. This simplifies the code and decouples the two concerns, making it easier to change things in future (i.e. once 404 caching responses are honored by the stack, we can more easily remove the code that publishes the "coming_soon" items without affecting the code responsible for pushing the publish intents).

Note that this reworks the existing interface to the `PublishingApiScheduleWorker`, which means that any jobs queued during the deploy of this code will fail noisily. To prevent this would require a lot of work (create a  second appropriately-named worker; deploy the code; clean up the old worker code once the old jobs have been worked off and deploy again; potentially repeat the process to rename the new worker to `PublishingApiScheduleWorker` because that really is the most appropriate name). Given the low volume of these jobs, and that this work is transitional (we aren't handling live content with the Publishing 2.0 stack), manually dealing with any failures seems a reasonable trade-off.