Display API abstraction

This MR is a simple rewrite of the Display-calling logic. The Display wasn't rewritten yet (only the way the calls are done), but this this a step that eases this process.

The main concern is that current display calling logic is heavily tied to display.js (there's a run_javascript function that runs the code directly on the JS world). This MR changes this by introducing a run_in_display function in window.py, adapting all the related calls and then creating a simple communication bridge on the JS side, effectively decoupling the Display logic from being tied to display.js. This makes easier to implement full custom displays (which I'm doing a rewrite of current display code in Angular).

• Adds a --display-custom-path flag on the command line, to allow to use custom displays (I've been using to develop the new display code; using this with QTWEBENGINE_CHROMIUM_FLAGS=--remote-debugging-port=<port> helps a lot);
• Adds a window_title on the DisplayWindow constructor that's used by the new bridge to set HTML window title (this way it's easy to distinguish DisplayWindows on the Chromium Debugger)
• Adds a display-init.js code on the HTML display folder, containing this new communication bridge;
  • It exposes three important items in window:
    1. The communicationBridge property, which contains the CommunicationBridge instance;
    2. The requestAction method, which can be used to call actions (functions) in display;
    3. The requestActionAsync method, which works with promise-based actions and triggers the provided event name via DisplayWatcher (some helper on the Python side will be written in future)
• Inserts code in display.js to call the effective functions when invoked from bridge;
• Adapts all calls to use new run_in_display method, which auto-converts parameters to JS notation (there's a raw_parameters named parameter that's still allows to pass raw JS values on parameters).