Refactor process of staging changes

This document describes improvements related to - solar ch stage, workflow that precede's it and related data structures.

Current implementation of staging procedure has at least 2 problems:
1. No way to stage part of your changes (ex. changes that are related to named environment (tag))
2. Limited to staging changes only to next action - run/update/remove (ex. stage restart/test/any_other action)
1 item is not simple inconvenience, but a blocker to provide multi-environment support.

Instead of keeping updated flag on resource and filter resources based on this flag - move this state to separate bucket, resource tags should be copied each time when resource is added to this new bucket.

1. Create model - StagedResources with fields actions, tags (IndexedField)
2. After following actions we should insert row in StagedResources
- resource create
- resource update
- resource removal
Optionally:
- add new command to stage any other actions
3. For create/update/removal we should take into account all possible updates in childs
4. Based on list of staged resources + affected childs - generate graph of changes (solar ch process)