Generalize editor result

[NKb03]

Some editors always produce a valid result. It should, therefore, be possible to implement editors whose result property is of type T and not of type Validated<T>. There are two possible solutions:

Easy solution

Create function defaultResult(): Validated<R> in Expander that can be overridden by subclasses to achieve that the result is always Valid. Plugins can then call force() on results when they know that the result is always Valid.

Pro

• This could be implemented quite easily and the API-changes would be backward-compatible.

Contra

• not the cleanest solution
• the fact that an editor always produces a valid result is not captured in the type definitions
• this leads to many unnecessary force() calls.

Complete solution

Change the type of result to R instead of Validated<R>. Editors that may have an invalid result can just pass Validated<R> as the type parameter.
There are however some problems with this solution.

1. There is currently no way to reflectively create editors for a generic type. This means we can not create an editor for result type ´Validated<T>.
   • use KType instead of KClass for registering editor factories
   • there is the typeOf function that can be used to get the KType instead of the KClass from a reified generic
   • should this also be done for EditorView factories?
2. How do the CommandLine, the SettingsEditor and the argumentPrompt know if the result of an editor is valid?
   • Add property isValid: ReactiveBoolean to interface Editor
   • Create editors by asking for an editor of type P and then for an editor of type Validated<P>
3. A ListEditor doesn't know if its child results can be invalid.
   • Create abstract function accumulateResults that is implemented by subclasses ValidatedListEditor and SimpleListEditor
4. The SyntaxErrorInspection only works for Editors with validated results
   • Use KType instead of KClass for registering inspections and commands

Pro

• clean
• this would solve fundamental problems such as generic reflective registration
• everything is visible in the types

Contra

• quite tedious to implement
• many major backward-incompatible changes to the API

[NKb03]

With the complete solution, the R : Any bound could be dropped.

[NKb03]

The complete solution depends on #47