3 new events are added, they are:
* STOPPING_SERVICE - published before service is stopped
* SERVICE_ITEM_STOPPED - published each time service item(like workspace) is stopped
* SERVICE_STOPPED - published after service is stopped
Resolves#3892.
Two API methods are available:
* _POST /api/system/stop_ - stops corresponding system services, for now it's workspace service.
Basically it stops all the RUNNING workspaces snapshotting them before if configured to do so,
also it interrupts start of currently STARTING workspaces.
* _GET /api/system/state_ - returns current system state(only status for now).
By default system status is RUNNING, but after stop is called or che server is
stopped directly system status is changed like the following:
```
RUNNING -> PREPARING_TO_SHUTDOWN -> READY_TO_SHUTDOWN
```
Status changes are followed by status changed events, to recieve these
events client has to subscribe on *system:state* channel.
So client can use different ways to track system status changes.
Doesn't matter whether API method is used or che server is stopped directly,
events will be sent anyway.
Roman Iuvshyn