Review how map config is generated at store level

[MV88]

Description

There is an historical implementation of how layers are managed and added to the application.
This way of updating map config state prevents easy way of overriding the state entering the loop of side effects that can not cover all possible cases
This might imply a breaking change as it is changing the way the core updates mapconfig state

See below possible options to explore / do

Acceptance criteria

• Here https://github.com/geosolutions-it/MapStore2/blob/master/web/client/stores/defaultOptions.js#L62 we split map and layers and then we add them to the application state
• mapConfig reducer is wrapped with splitMapAndLayers and this might go inside the reducer logic
• Alternatively we should check if it possible to apply changes to actions payload before they are sent to the reducer. like with an override at webpack level from a standard mapstore project
• if splitMapAndLayers was needed for createHistory, wouldnt' be possible to remove the history feature or implement it differently without impacting store this way?

Other useful information