Reuse normal field types for modvars

[Guite]

In the DSL of MOST we have entity fields and variables (config settings). In the generated modules we use Forms for both areas (editing an entity vs. changing the config).

We should remove variables and instead reuse the entity field elements (like StringField or EmailField) for modeling configuration settings, too.

The generator can still generate the current config pages from that, as there is still a big difference: modvars described in a model are not contained by an entity element, but by a modvars element. So the idea of this ticket is to get rid of modvar field type elements (like IntegerVar or StringVar), as these seem to be redundant.

Benefits:

• no additional / special model elements requiring separate processing in all layers
• several existing constraints, options and behavioural extensions can be reused for config settings
• less elements needed in the ModuleStudio editors palette

DSL tasks:

• change meta model to allow normal fields as children of variable containers
• update validation constraints accordingly
  • a field does not necessarily have a data object (mapped superclass, entity) anymore
  • throw error for obsolete model elements
  • provide quick fixes for easy migration
• update docs (validation reference, generator reference)

Tooling tasks:

• remove variable elements from editor palette
• update container mappings for variable containers (to allow fields being added)
• hide some options in the properties view if a field is contained in a variable container
  • no extensions supported (would require a "real" entity)
  • also hide some general properties (displayType, dbName, primaryKey, unique, ajaxToggle etc.)
• update docs (tooling chapters, editor layers)

Generator tasks:

• Update PersistenceTransformer
• Refactor references to obsolete DSL elements
• introduce an AppSettings class
  • one member var for each field
    • avoid any entity-specific annotations (orm, gedmo)
  • accessor methods for each field
    • avoid any entity-specific extensions (e.g. notify change tracking policy)
    • ensure that modVar values are correctly casted for Sf forms compatibility
  • add service definition
  • two methods like load() and save() both using the VariableApi
  • call load inside constructor
  • ensure composite property is still properly handled
• integration
  • extend ListEntriesHelper and reuse ListEntryValidator
  • extend UploadHelper
  • call save as part of form submission handling
• update generator for config form type, reusing existing form field implementations
  • use AppSettings as data_class for the settings form type
• update generator for config page template
  • reuse client-side validation
  • JS calls
• handle user fields
  • persistence
  • deletion listener (AccountDeletionHandler property)
• update docs (generator reference) (e.g. doctrine extension related properties are ignored for modvars of course)
• test generation

#139 is about removing meta model support for special modvar elements afterwards.

[Guite]

Fixed in e725fe6