Imperative interface to a running Libretto program

[TomasMikula]

Interaction between a Libretto program and components of the host language can in principle be done in two ways:

1. Libretto program is the master that embeds and manages pockets of (effectful) host language code.
   This is supported via Resource Management (Embedding effectful Scala #2, Resource management #10).
   It has a framework feel to it—everything has to be shoehorned to satisfy the framework requirements, in this case, software components of the host language have to be recast as resources in a Libretto program. The problem is that it is not always possible or desirable to make Libretto the main driver of the application and subjugate everything else to it.

2. (Running) Libretto program is recast as a component in the host language interacted with by the usual means of the host language (methods, callbacks).
   Benefits:

   • Does not require subjugation of everything else to Libretto.
   • Does not require a DSL that supports embedding Scala code. Using a weaker DSL means more things can be done with blueprints.

   NB: The interfacing code in the host language does not have the nice properties of Libretto programs, like ensured linearity, but that is an inevitable price to pay for interfacing with the dirty world of the host language.

This task is to support the second approach, namely to embed an instantiated Libretto program into the host language, by providing an imperative interface for interacting with it.

NB: It is not acceptable to embed mutable objects in a blueprint and then manipulate them from the outside. This might seem obvious, but it is a common practice in IO monad-based effect libraries. For example, it is common to create a blueprint IO[A] that captures a queue (mutable object) which is manipulated from outside the blueprint.

[TomasMikula]

Depends on #46 (Reference Implementation): Since providing an imperative interface is tightly coupled with the implementation, it is preferable to first implement #46 to avoid doing the work twice (once for the current PoC implementation and then for the reference implementation).