[Review Only] Landing CDT-independent livedev implementation

Brings in new Live Preview implementation incubated at njx/brackets-livedev2 which allows running on multiple browsers (more details on the internals at ```README.md```). The new implementation can be used as a swap-in replacement of the current ```LiveDevelopment``` implementation. 

Set ```livedev.multibrowser``` preference to true in order to make it work. If enabled, it will launch the page in your default browser when clicking on the Live Preview icon as it works today. You should then also be able to copy and paste the URL from that browser into any other browser, live edits will then update all connected browsers at once.

Main assets will land under ```LiveDevelopment/MultiBrowserImpl``` while the main module ```LiveDevMultiBrowser``` (equivalent to ```LiveDevelopment```) will land under ```LiveDevelopment``` folder. This is probably not the more elegant choice but the decision mainly relies on these two needs:

 * Keep current modules from ```LiveDevelopment``` without moving them from the original place since many extensions require them as dependencies
 * Keep multi-browser implementation under this folder since it is an (still experimental) implementation of ```LiveDevelopment```.

Changes included in ```LiveDevelopment/main.js``` allows managing both implementations. Both modules are loaded and initialized. A listener for preference changes is in charge of setting the active implementation based on pref value. Current implementation will be active and work as today by default.

There are still key things to do (launchers for particular browsers, UX/UI, multi-host support, unit/integration tests that run on different browsers, among others). Some of them will also need some previous discussion but, it is important to get this implementation landed in core so we can get some feedback from developers and also submit PRs that allows evolving it including changes that could potentially impact some areas of the underlying infrastructure.
To make this change (in a clean way) I think I would need to change ```LiveDevelopment/main.js``` to dynamically load modules and move all the specifics things  of the current implementation from ```main.js``` to ```LiveDevelopment``` module probably (eg. Inspector initialization). Not sure if that could introduce some issues with the current implementation but also with extensions that depends on it.

Making status/tooltips as a preference would probably make every developer have to know and write their values every time they want to switch among impls. The new implementation was aligned to the current UI just to make simpler its integration but, I think it is not its natural UI. It could have multiple instances running on different browsers which should be monitored/controlled somehow, even the concept of live preview session and its states would probably change. Not sure about this, I don't like current solution either, it could eventually be moved to some a config file or behind each module implementation.

Moving the new implementation back to be an extension and make it switchable with the core implementation is something I didn't try before. I assumed not to be an extension because we thought it would replace the current implementation in the long term and provide mechanisms for extending it by building custom transports, launchers, protocol methods, remote functions, etc. I didn't take into account building custom implementations because it seemed to me that building an abstraction layer on top of the current ```LiveDevelopment``` wouldn't be easy.