Web server workflow-related state refactoring

[shengquan-ni]

Workflow State Store
According to our discussion, we want to separate data and logic for each component class in our webserver. So I used protobuf for the data class and added a SyncableState (any better names?) to wrap the modification. I created a centralized store for all data classes. This centralized store is called WorkflowStateStore and is passed into every service component. The service component can subscribe to any state change and push events to the frontend as a reaction. It can also actively modify any state based on request and this modification will also be observed by other components.

Reason to use protobuf
Although protobuf increases the transmission efficiency but the biggest reason I want to use it is not about that. Protobuf gives us a unified way to define data classes. Since we have the typescript-based frontend, a java/scala/python-based backend, we don't want to write the same data class in different languages. Another reason is that protobuf objects are immutable so we can easily write the onChanged API and enforce developers to follow this API to modify the state. Right now protobuf data classes only stay inside the backend. When we send those data to the frontend, a conversion to TexeraWebsocketEvent needs to be done so that we can hook up with the existing json serialization/deserialization. In the future, we may replace json with protobuf serialization.

Websocket Input
This module provides an observable of frontend requests to workflow internal components inside the web server. So every component has a chance to subscribe to specific events they want to handle.

Lifecycle Manager
This module controls the lifecycle of a workflow state. As I stated before, there is a counter inside each workflow to maintain the current number of active users. Once all users disconnect AND the workflow is not in a running state, the cleanup logic will trigger.

[zuozhiw]

Looks good, left a few minor minor comments.