It is meant to be used as inline positioned (sub) element. Therefore it 
has not postioning information and less property options than the normal 
drop list. Similar to the simple text field.

MatButtonModule is used in all projects!

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.

Similar to a text element but parses the text on change an replaces 
markers with actual elements.
The text is then displayed inline with the elements.

This element has a list of string as editable options. Those strings 
form draggable elements which may be reordered or moved between 
different DropList elements.

Also refactor option change logic to allow any property not just the 
text property.

This works similarly to the standard radio group, but has a fixed 
horizontal layout with images above the options.

Add styles for bar and buttons

to avoid name collision.

This was an early draft and unused. Will be reintroduced in a proper 
form later.

* 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.

The urls must be declared as trusted to be accepted by the application.

Also some small improvements to variable naming and file structure.

#23

Move `MatDialogModule` from editor to common
Add `AlertDialog` to player

more information about [ngx-translate](https://github.com/ngx-translate/core)

- Service is used by the editor exclusively so definition in
local app.module.

- Edit dialogs triggered via double click on drag overlay
- Unit Service now defines a default edit dialog for elements. For now
label or text if available.

Since this does not label anything but instead is meant for (longer)
texts.

* 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 defines the elements priority when stacking elements on the canvas. 
Directly maps to the CSS property.

Also show tooltip on the input to explain what it is for.

The extra styling via panelClass needs CSS definition in local project, 
so can not be set by the Service itself but relies on local CSS rules.