UI activities

A UI activity can be used to orchestrate the display of screens in a given UI application. The UI application might be a WinForms app, an MV or Razor pages app, or indeed, a Blazor (WASM and/or Server) app.

This feature comes with 2 concepts:

**1. Activity**

The key is for this kind of activity to be an abstract representation of a **view** in an arbitrary UI.
By "view", I mean anything that could be a screen, a step in a wizard, a controller action, a Razor page, etc.

The activity would contain at a minimum some identifier for a given view, and a property bag that will be made available to the view when being presented by the UI app.

The property bag could even be used to store UI information that can be used by the UI app to construct the view.
For example, it could contain a form definition in JSON format, which the UI app uses to display a form.

The activity would be a *blocking* activity, creating a bookmark that is to be resumed from the transport (see below).
The transport can provide data from the UI that is then made available to the activity as it resumes execution. This data is available as activity output so that the workflow might act upon it. If an activity executes that holds any data, this data is provided to the transport. This allows for ste-by-step wizard applications to display existing form entries, for example.

**2. Transport**

The _transport_ is what connects the workflow with the UI, and is tightly-coupled to the UI framework being used for the UI app.
For example, if the UI app is an MVC web application, the transport could be as simple as a classthat sends HTTP Redirect responses to the current HTTP response.

Another kind of transport could be based on SignalR, where the workflow server emits events that are captured by this bridge, sending messages via a hub to the connected client.

An existing POC built for Elsa 2 can be found in [this repository](https://github.com/cristinamudura/elsa-onboarding-poc) created by @cristinamudura.