Remove manipulations from elementModel
- Refactor drop list component
- Use of initial values for audio and video playback time

Defining the validators not in the elements anymore, but when creating
the forms

This helps to divide the code of the element container into smaller
meaningful units.
In addition, each element can be given its own form group.

This removes all the classes and goes back to simple interfaces for
unit, pages etc and all elements. This makes creating them easier and
cleaner.
Things like specific needs when setting element properties and most
importantly compatibility handling is done by a special service module,
that knows all the elements and how to repair old their potentially
outdated definitions.

Prevent sending a valueChange notification

Do not consider all form elements, but use a list containing only form
elements with validators

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.

This is a native input element which is used in cloze elements. Here 
(sub)elements need to be positioned inline, which is hard to do with 
material components.

Also add a method to all form elements to set their form value, which is 
now only used by the simple text field but may be useful for other 
elements, which don't integrate in material form fields.

Also all elements now take the parentForm as input. Allowing it to use 
them with template binding and not only setting the value directly (in 
the controller).

All elements now use the elementValueChanged event. Also
formValueChanged is changed.

* Remove FormService Injection
* Move FormService and form types to player
* Move interface ValueChangeElement to uI-element.ts
* Use interface InputElementValue instead of
string | number | boolean | null

This makes checking the existence of properties for the property panel
possible, since it is possible to check for null but not for undefined.

Overridden by some child elements (TextField, CheckBox)

* 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

* Move setting of validators from `FormElementComponent` to
`ValidationMessageComponent`
* Add validators and warnings to `ValidationMessageComponent`
* Move subscriptions for form controls and their validators from
`PageComponent` to `FormComponent`

* Register `PageComponent` as child formGroup, so that values for
any page can be sent to the host.
* Register formControls as controls of the page

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 wrapper of the player component listens to the `valueChanged`
event and posts a message to the host of the aspect-player
* Improve code style and remove lint errors

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

Remove unnecessary decorator and variable initializers from
`CanvasElementComponent`

Shift the order of style assignments in `updateStyle` method

This is part of trying to solve the problem of upating styles on already 
rendered components, but still does not work.

THis makes the  components usable in other contexts (player) as well.

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.