Improve components architecture - SyncResourcesModal, PublishModal and ProgressModal

Summary

Currently, SyncResourcesModal/PublishModal is responsible for the first half of the sync/publish workflow and ProgressModal for the second half, where ProgressModal needs to figure out if sync or publish is running and, based on that, decide what content should be rendered. This is most likely due to how we used ProgressModal in the previous Studio version.

There are several disadvantages to this approach:

• Fragility: We have to be sure that a component responsible for the first half disappears properly before a component for the second part takes over. Together with the fact that both components contain quite a lots of conditions and are connected to the store, this seems to be prone to unnecessary problems.
• It's not possible to easily implement consistent transitions between all steps of sync/publish processes
• Confusing for developers

I'd suggest having only SyncResourcesModal and PublishModal. There will be relatively a big portion of shared general tasks logic. We can review what needs to be reused and extract it to a mixin or alternatively, it may be interesting to explore a renderless task progress component encapsulating shared logic (similarly to how we use Uploader component that has proven to be very flexible and readable).

Start by locating SyncResourcesModal, PublishModal, ProgressModal, and the existing Uploader component, then trace how the sync and publish workflows move between modal steps and the store. Done means the workflow is owned by SyncResourcesModal and PublishModal with shared task logic identified and consistent transitions supported, without ProgressModal deciding which workflow is active.