melange: introduce `melange.root` stanza, to avoid duplicated .js artifacts

At the moment, every melange.emit stanza generates its own version of the js artifacts produced by the libs it consumes. It there are N melange.emit stanzas using the same library foo, the js artifacts for foo will be found N times under the _build folder.

Besides unnecessary disk space usage, this is problematic for build tools like webpack, that become slower as they have to process the same files multiple times. It is also punitive for the resulting JavaScript bundle size, as it is not possible out of the box to reuse the same library js bundle in multiple places, unless one goes going through complex webpack configurations.

To avoid this, @rgrinberg suggested the idea of introducing a new stanza melange.root. This new stanza would define a target, and the javascript_extension and module_system used by that target, e.g.:

(melange.root
 (target tools_es6)
 (module_system es6)
 (javascript_extension js))

Then, afaiu, melange.emit stanzas that are spread across the project folders would be used to define "entry points", referencing the target already defined in melange.root, e.g.

(melange.emit
 (target tools_es6)
 (alias melange)
 (libraries lib))

The fields module_system and javascript_extension would be removed from melange.emit.

Some open questions:

• Should melange.root be in dune or dune-project file?
• Is it possible to solve the duplication problem without adding a new stanza?
• If melange.root was ultimately added, would it make sense to rethink stanza naming? e.g. melange.emit could be rather melange.entry_point or melange.executable, as it would not be really emitting anything anymore. And melange.root could be melange.emit instead.

Start by tracing how melange.emit stanzas produce JavaScript artifacts and how targets, module_system, and javascript_extension are handled. Compare the proposed melange.root design with the alternative of solving duplication without a new stanza, including whether it belongs in dune or dune-project. Done means shared library artifacts are no longer duplicated across entry points and the stanza naming and configuration are settled.