Trying to find out why I kept having a bunch of leftover `tmpsomethingsomethign_chrome_odoo` leftovers I realised #203412 had a bit of an error in the location of the
`atexit.callback(browser.stop)`: the temporary directory for the user data dir is created as soon as the browser is instantiated, but the cleanup is only recorded after a successful `navigate_to`, so if that (or a previous step e.g. authentication) fails then the tempdir is never cleaned up.

Rather than just move the call up the body and re-introduce conditionals to `stop` to handle more partial initializations though, use the magic of ~~buying two of them~~ `ExitStack` to record cleanup requirements dynamically as the `ChromeBrowser` initialises.

This initially used a bunch of `ExitStack.callback` calls with ad-hoc cleanup, but turns out most of these cases are better as CMs:

- replace `mkdtemp` / `rmtree` by `TemporaryDirectory`, which Just Works as a CM
- add context-manager methods to the screencaster classes (also remove `stop` which is redundant with `__exit__`) so they Just Work as CMs
- convert `_chrome_start` and `_open_websocket` to `@contextmanager`... for obvious reasons

This makes the relation between setup and cleanup clearer, as well as more self-contained in case we want to move stuff to a submodule eventually. It also ensures cleanups run in the correct order, and avoids having to deal with partial initializations.

Keep `ChromeBrowser.stop` because it seems unnecessary to edit those out for now, but have it just `close` the exitstack (which runs all the registered cleanups).

NOTE: it might make sense for `browser_js` to just use `ChromeBrowser.cleanup` instead of having its own exitstack, not entirely sure... Alternatively it might make sense for ChromeBrowser to *take* a CM as parameter... and / or for ChromeBrowser to *be* a CM?