Chrome's screencast / remote view (in the remote devtools) is apparently *designed* for touch emulation / simulation (https://crbug.com/1410433), which is not convenient when trying to debug mouse-bound issues in a tour (e.g. drag&drop problems).

This can be solved by just running the browser normally if the user wants to watch, in which case the user can also use their normal devtools.

However this doesn't work with the current architecture, where the browser is lazy-started one per test class and reused between `browse_js` calls.

Scrap that, run and shut down the browser entirely for every `browse_js` calls that way it's possible to use entirely different browser. This also simplifies the cleanup phase somewhat as we don't have a persistent profile directory to try and reset, instead every `browse_js` has its own.

Notes:

- `--no-first-run` causes tours to not run at all on my machine, in a non-headless browser
- also moved a bunch of other flags which seem to be mostly for automated annoyances to headless only
- left extensions for now, not entirely sure which is the right one, since we're running with fresh profiles I would assume there's no extensions anyway

Currently from the pos_self_order app a customer can only view the menu.
This PR adds the option to order items.
A customer of the restaurant will now be able to scan a qr code on their table, and navigate to a website where they will be able to order items from the pos. 
The customer can select product variants and add a specific notes for each of the ordered products.

This version does not support online payment. This means that the customer will still have to pay by the usual methods.

The pos can be configured such that a customer can add items to an existing order. For example, ordering a second coffee will result in an update of the existing pos order containing the first coffee. Alternatively, the pos can be configured such that each order made from the web app results in a new pos order. Orders made from the self order app will be placed in the same pos session as regular orders. Once a customer orders from the self order app, a new order will appear in the pos app. Thus, a waiter will be able to quickly see all the orders placed by customers from the self order app. He/She will then be able to send the order to the preparation display. This step has to be done manually.

In the interest of security, each table now has an associated access token. It is included in url that the customer gets from the qr code. When sending the order, the self order app also sends back to the server this access token. The server will only process the order if it receives a valid access token. When placing an order, the server will respond with the pos_reference and access_token of the created order. The web app will keep this data and will send it back to the
 server as a proof of ownership in the event that it intends to get the latest state of the order or to update it. The server will only reveal information about an existing order when the request contains a valid pair of pos_reference and access_token.

Task: 3058586


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr