Do not run BabelMultitargetPlugin in dev mode by default to speedup initial webpack build

[pleku]

On a fast laptop:

If I run 14.1 with the multitarget plugin without a node_modules folder, webpack takes about 22 seconds.
If I run the same thing without the multitarget plugin, it takes 6 seconds (edited)

The difference for later compilations is not as huge though. 7.1s vs 9.7s

Thus for development mode, we should make BabelMultiTargetPlugin to be only run on request when the developer wants to test with older browsers.
For production mode, it should stay as always run by default, but probably could make sense to (in a separate step) make that also configurable (separately to development build).

Acceptance Criteria

• Make BabelMultiTargetPlugin triggered for the webpack build only if the parameter devmode.transpile (or better name) is set to true
• When the application is run on devmode and the app is opened with a browser that would require the ES5 transpiliation to be used, replace/supplement the unsupported browser page with the instructions on how to enable the ES5 transpilation for development mode, and highlight that it is done out-of-the-box for the production build with build-frontend goal
  -> this needs to be done for any browser that will now start failing in devmode without transpilation
• Document the new configuration into https://github.com/vaadin/flow-and-components-documentation/blob/master/documentation/advanced/tutorial-all-vaadin-properties.asciidoc
• Update the documentation in https://github.com/vaadin/flow-and-components-documentation/blob/master/documentation/v14-migration/v14-migration-guide.asciidoc about testing with IE 11
• Add the configuration property to Spring Boot so that it works on those apps too
• Create a demo where the startup bundle difference is shown compared to 14.1 when webpack bundle has been deleted

[pleku]

In practice, we need to push the plugin to be run only when a given parameter is set for the webpack plugin. It is not worthwhile to generate another webpack config based on this because that is part of the prepare-frontend goal and thus not feasible. Also then the same webpack config is used for both development mode and production mode, but it will just be run with the different parameter setting.

Currently reported ES6 support https://caniuse.com/#feat=es6

This feature is unnecessary for Flow 3.0 because it doesn't have the plugin anymore, so it should be targeted tot 2.2 branch.

[pleku]

To see an example on how to pass a parameter to webpack, there is the watchdog server port passed from Java to the webpack configuration.

[Artur-]

Does the parameter need to come from Java instead of user’s webpack.config.js?

[pleku]

Does the parameter need to come from Java instead of user’s webpack.config.js?

IMO it should be possible to configure it in Java when you decide to run your application server like mvn spring-boot:run -Dvaadin.devmode.transpilation=true. I would not want to touch some webpack config file for this and I'm willing to bet that many users would not too. The cost for adding it such way is not much.

Do you @Artur- see additional benefit in having it explicitly in webpack.config.js also where you can set it ?