Use case description

Derived from #8364 which was narrowed down to other processing flow improvements refactor

Currently internal flow of processing commands is convoluted and confusing in many places. In result there's a dependency between parts for which there is no reason to depend on each other (e.g. we cannot do sls deploy --package outside of service context, while after all outcome doesn't depend in any way on the current working directory context).

Additionally we should cleanly separate Packing and Deployment phase, taking into account case reported at #3528 where's there's reported need for builds that can be reused for any stage or region.

Ideally internal handling should be as follows

1. Packaging step, should package binaries and store resolved state of service configuration, but we should not generate CloudFormation template to be deployed at that stage.
2. Deployment should consist of:
   1. Generation of ready to deploy CloudFormation template
   2. Upload artifacts
   3. Deployment of CloudFormation stack

In this context it'll be good to also address #2202 (provide a mean to run sls remove --name <service-name> outside of service context

Proposed solution

TBA