Implement handling of command rejections

[dpikhulya]

This PR generalizes CommandOutcomeHandler to a more capable CommandLifecycle object, which can be configured to handle different kinds of situations that can happen when posting the command:

• One or more possible expected non-rejection events, which are considered as a "positive" command posting outcome (which typically closes the dialog as expected).
• Zero or more possible expected rejection events, which can come after posting the command. By default, CommandLifecycle displays a configurable message for them, but it's possible to override this behavior either for all rejections at once, or on a per-rejection basis.
• Posting errors.
• Outcome waiting timeouts.

By default it displays configurable messages upon either of the "negative" scenarios, but handlers for those scenarios can be customized.

Here are some usage examples (see the KDocs for all configuration parameters):

    val command: SomeCommand = someCommand()
    val succeeded: Boolean = command.post(
        CommandLifecycle({
            event(
                ExpectedEvent::class.java,
                ExpectedEvent.Field.id(),
                command.id
            )
            rejection(
                ExpectedRejection::class.java,
                ExpectedRejection.Field.id(),
                command.id
            )
        })
    )

An example of per-rejection and common (all-rejecctios) custo handling:

    val command: SomeCommand = someCommand()
    val succeeded: Boolean = command.post(
        CommandLifecycle(
            {
                event(
                    ExpectedEvent::class.java,
                    ExpectedEvent.Field.id(),
                    command.id
                )
                rejection(
                    ExpectedRejection1::class.java,
                    ExpectedRejection1.Field.id(),
                    command.id
                )
                rejection(
                    ExpectedRejection2::class.java,
                    ExpectedRejection2.Field.id(),
                    command.id
                ) handledAs {
                    showMessage("Custom rejection message for ExpectedRejection2")
                    anyOtherCodeForThisRejection()
                }
            },
            onRejection = { command, rejection ->
                showMessage("Rejection ${rejection.javaClass.simpleName} was " +
                        "received as an outcome for command ${command.javaClass.simpleName}")
            }
        )
    )

---

Besides, this PR contains:

• Updates of CommandMessageForm, CommandWizard, and CommandDialog implementations to use the new CommandLifecycle object instead of the old limited event subscription that they were using up to now.
• Dialog revisions:
  • Renamed the notion of dialog's "display mode" to "window type" as that is a more precise term for what happens, and extracts the respective window type implementations into a separate file.
  • Renamed Dialog's dialogWidth/dialogHeight properties to width/height (to remove the redundancy in naming).

[armiol]

@dpikhulya
Let me suggest an alternative approach:

  val command: SomeCommand = someCommand()
    val succeeded: Boolean = command.post(
        SubscribeTo({
            events<ExpectedEvent>(
                ExpectedEvent.Field.id(),
                command.id
            ),
            rejections<PossibleRejection>(
                PossibleRejection.Field.id(),
                command.id
            ) handledAs { ... }
        })
    )

Notice the change in wording. And also, the generic parameter (which you can infer in Kotlin, AFAIK), instead of the first argument.

Do I understand correctly that the subscription by any field (not just by Field.id() is assumed?

[armiol]

@dpikhulya another question is why we have this duality in your code:

rejection( ... ) handledAs { ... }
// ...
// and then suddenly, again
onRejection { ... }

To me this looks like two ways to do the same. And this is somewhat confusing.

[armiol]

@dpikhulya please see my comments.

[armiol]

@dpikhulya one more thing. Events and rejections in Spine know about their origin via EventContext, so theoretically, there is no need to specify the ID when subscribing.