The problem being solved is that compound-sub-elements must not have
all the properties other elements have. For exampe positioning info.
Sub-Elements are positioned inline. To avoid having similar class
inheritance structures for positioned and inline elements, we use
interface. Positioning is done via interface and is therefore optional.

Those optional properties are kept in an object in a variable. This
allows to hide specifics from element classes and removes the need to
initialize all the fields in every class using the interface.
The elements mostly care about their own specific properties anyway.

The same technique is used for font and surface elements. Here we also
don't want to initialize all the styles in every class.

Changing values of element properties works like before. Just set the
property as if it would be a direkt prop of the element. The element
itself puts the value in the currect sub-object (positioningProps,
fontProps etc).

For reading the values there is a similar method, but it is not used
anywhere by now. Since the properties panel operates on the raw values
anyway (refer CombinedProperties) and for element components this would
mean calling a function in the template, which caused change detection
to run the function very often and is therefore bad practice.

Additional notes and refactorings:
- Restructure all files in common. UIElements in the same folder etc.
- Move all interfaces to the UIElement file. This avoids circular
  imports, which would be needed to allow PositionedElement to extend
  UIElement.
- Interface initializers also handle reading values in the old form.
- Add PositionedElement for use in canvas overlays. This is a UIElement
  with guaranteed postionProps.
- Don't export all Material packages from common, only the ones
  used in player and editor. The rest is only used in common and
  does not need to be exported.

The issue here is the alignment if dropLists and text fields. They are 
supposed to be exactly in line with the text which is very complicated 
with Material components, which are heavily nested and contain several 
sub-elements which need to be changed - removing margins, paddings and 
other position related styles.

Setting on type button avoids that click events are evaluated from
the surrounding form

This allows to use them in template bindings. Used in compound elements.

This change mainly helps the editor.
The idea is to make the element components have the correct value of
their model and don't rely on the formcontrol value. The formcontrol
can be hard to manipulate, especially in compound elements. Setting
the model value is way easier.

The formcontrols are kept and should not interfere.

For elements which don't have this functionality the workaround is to 
use pointer events and make the elements unclickable.

When the label is empty a smaller input field will be rendered which 
also does not have the label placeholder.

This makes a small (suffix) button appear which clears all the input of 
that field.

- Remove interfaces
- Add classes for all elements as well as unit, page and section
- 2 intermediate interfaces are kept. They dont constituate a viable 
object but only additional properties, like background-color. Those can 
be added as interface to all elements. Initialisation has to be done by 
the element itself though and not by some constructor higher up.

* When elements receive the focusin event, their status is changed to
`TOUCHED`
* Replace `this.form.valueChanges` subscription with
`this.unitStateService.unitStateElementCodeChanged` subscription

* Delete validation message component
* Use instead `mat-error` inside element components to take advantage
 of `mat-input-field`
* Add get validators method to each form element component
* Display validation messages via `error-transform` pipe

Since the material elements don't give a way of applying the background 
color, a hack is needed to get the internal elements and apply the 
style.

Directive to be able to do it for text field and text area.

Also some small improvements to variable naming and file structure.

#23

This is in preparation for dynamic layouting.
The actual dimensions are set by the overlay component which differs but 
is existent for both editor and player.

Both use the property name 'min' and 'max' but map it to min/max and
minlength/maxlength respectively.

Also refactor a lot of stuff belonging to this:
- You can edit the default values via properties panel
- All elements now again have a common parent directive. form elements
have a special parent for forms.

* When creating components for each element a
`ValidationMessageComponent` is also generated dynamically
* Prepare usage of default values for form elements
* Add `form.ts` for form specific interfaces
* Rename some variables and properties

* Only elements which has to be registered by the player's form inherit
from `FormElementComponent`
* Element components use their specific `elementModel`
* Rename file for `FormElementComponent`

The UIComponents now only have the properties they can make use of. This 
means that the angular components use the CSS properties explicitly 
instead of having all kinds of useless CSS properties.
Also it is no longer needed to update the CSS styles via event because 
Angular's change detection takes care of that.

Use `parentForm` input in `PageComponent` and in `SectionComponent`
instead

* Introduce `FormService` to provide communication between
element components and form
* Add `ngModelChange` and `formControl` to
some element components. This functionality is not used by
the editor

This makes the actual component elements agnostic to any drag and drop 
and selection logic, which is handled completely via the 
wrapper-overlay. Now the component elements can be easily used by the 
player.

They will be reused by the player.