WIP: Schnappsidee: Provide alternative for client eval's conditional logic and hidden fields

[mhsdesign]

This is just a wip thought and will be better formulated and discussed at a later point.

Current state:

• ClientEval is hacky and ugly and must go
• Hiding things and validation is not a good idea: BUG: NotEmptyValidator blocks saving Inspector changes, even if the field is hidden #3549

Proposal:

instead of conditionally selecting an option, we declare union types and a higher level editor in the neos ui will give a selection to either insert the one or the other:

properties:
  myConditionalType:
    type: string|\SomeDto

So when selecting "string" (or rather a human readable label) a string editor appears and when selecting "SomeDto" or the like another editor appears.

To correctly model complex things inspector gadget should be used - and might even need to be brought to the core ... maybe even union types are not really necessary, but inspector gadget would already solve all problems though the use of well structured custom dtos?

[Sebobo]

DTOs don't sound a like an easy and accessible solution to me for integrators and for most simple cases. Also things evolve over time.

But if someone wants validation + optional fields, they have to provide one, as it sounds a like a bit more sophisticated use-case. We can also make the ui detect if something is hidden+hasValidation and show a hint to the editor.