[meta] decoupling from ipfs-webui

> Just writing down some thoughts and concerns, needs more analysis, probably can be split into 2-3 phases.

Right now ipfs-desktop is tightly coupled with ipfs-webui:
1. ships with a bundled version of ipfs-webui
2. opens bundled webui in Electron's webview
3. injects own settings into Settings screen of ipfs-webui

I believe it comes at significant maintenance cost and user confustion:

- requires ipfs-webui to support Electron "browser" and things such as drag&drop broke in Electron before (#1287)
- every time new setting is added, ipfs-desktop release is blocked by ipfs-webui, and same for bugfixes (eg. https://github.com/ipfs-shipyard/ipfs-desktop/issues/1290)
- running Electron webview in the background wastes CPU and memory (not as much since it is now "paused" by switching to a blank subpage - https://github.com/ipfs-shipyard/ipfs-desktop/pull/1198 - but still wasteful)
- when user opens webui from commandline or via browser extension they see the same ipfs-webui, but when they go to Settings ipfs-desktop options are not there (they are there only if webui is opened via ipfs-desktop menubar)

I suspect we could consider:

- remove Desktop-specific items from Settings screen in webui, and put them in menubar submenu instead
- opening webui from `http://127.0.0.1:8080/webui` instead of `webui://-` pseudoprotocol
- **ensure offline use case works**: if we stop bundling webui with ipfs-desktop and open webui in a web browser, then we need to ensure the proper CID is already in the repo
- we have prior art of doing just that in Brave: ipfs-companion is bundling TAR archive for webui CID and during the startup in Brave checks if it is present in the repo, in not, it imports data from the TAR. Code in [precache.js ](https://github.com/ipfs-shipyard/ipfs-companion/blob/v2.11.0/add-on/src/lib/precache.js). This ensures webui is always present, and fast, even if initial load happened in "airplane mode".
- opening in real web browser instead of Electron