Internalize mapbender versioning into mapbender repository

[werrolf]

Branding, the everlasting joy of life.

This provides Mapbender-internal Mapbender versioning and naming, while still supporting explicit project branding overides.

A new compiler pass displaces fom: server_version et al as the authoritive source of the Mapbender version. Mapbender gains version knowledge inside itself.

Any server_version or server_name values configured in FOM that follow certain well-treaded patterns are dropped on the floor and replaced by Mapbender's own. If they deviate significantly from historic default values used in vanilla Github versions of Mapbender Starter, we treat them as desired project-specific overrides and leave them alone.

We also add new parameter keys for direct project-specific overrides of name, version and logo. These will always win out, even if they happen to say "Mapbender3" "v3.0pre2" (which would be ignored if it appeared under fom : server_*).

Motivation: currently, git tags are the only hard source of Mapbender versioning information inside the actual Mapbender repository. fom: server_* is defined in another repository. This mandates parallel updates of multiple repositores at every versioning cycle and throws a wrench into introspection.

This pull obsoletes Mapbender version information in Mapbender Starter.

[werrolf]

We now also get a console command mapbender:version. This is intended mainly to feed into outside scripts that require a version for packaging or other tasks, such as ComposerBootstrap::genApiDocumentation.

With the following in my parameters.yml:

parameters:

    branding.project_name: Awesomebender
    branding.project_version: 9000

I receive the following output:

application$ app/console mapbender:version
Mapbender 3.0.7.4
application$ app/console mapbender:version --project
Awesomebender 9000

Likewise, my backend now displays v. 9000 top-right, and my unmodified AboutDialog welcomes me to Awesomebender Version 9000.