Improve the launch & onboarding experience for first time, and subsequent users

[Faithkenny]

Overview

This ticket seeks to cover the user scenarios encountered when the ODE is launched.

We have revamped the launch flow, and interface design such that it's much clearer for users to understand what's happening after the ODE is opened. This flow ultimately lead the user to the welcome screen.

This also addresses the initializing message problem of issue #418

As this is the first impression of the product, it is designed to have a modern feel, and seamlessly integrate into the Frictionless Data brand & visuals.

Successful, and fail states for a first time run, loading and the welcome screen are addressed here

1. First time run - where installation and dependencies download is successful

https://github.com/okfn/opendataeditor/assets/81084607/8fb0a350-b290-444b-a484-87cc6a7c9807

2. First time run - where installation fails

https://github.com/okfn/opendataeditor/assets/81084607/cb54ac78-df11-4ce0-af14-25cc766a5e47

3. Subsequently, users have fewer steps before getting into the main product

https://github.com/okfn/opendataeditor/assets/81084607/c63a6321-4d89-42f9-8a01-43349ee7f7fa

These are the 2nd iteration of the proposed solution after internal review. Here is the Figma file if you'd like to dive in:

https://www.figma.com/design/cOpYjy35zB3dJf1GW1BC76/Open-Data-Editor?node-id=642-6671&t=CkmfNFDyL9B9AhIG-1

[pdelboca]

@roll @guergana in terms of implementation we can clearly separate this issue into 3 independent issues. If I would suggest a path I would say that we can implement the welcoming screen, the loading screen and lastly the error handling.

1. First time Run - Successful

We already have an codebase aligned with this idea, however we need to refactor some things a little bit. We currently have 2 steps:

1. Start the Electron Application + FastAPI Server.
2. Run the application (and waits until FastAPI server responds).

As I mentioned in #446 we need to migrate the logic that waits for the server to the desktop module so we can properly handle errors and display the messages. In terms of implementation, I suggest to refactor the current logic implemented in the onStart method of the store, extract the waiting for the server and move it to the desktop module. Leaving in the onStart method all the logic to load the configuration and stuff.

2. Handle Errors when loading the application

Another independent ticket is to handle the scenario where the application fails to load. After #446 we should have less scenarios that could fail but even so errors could happen and we should handle them. In terms of implementation I'm wondering if we should start the application (and show the error). Or simply show them in the context of the loading screen. Should we start the application with an "error" state to show an error dialog? I'm open to suggestions here.

3. Welcoming screen

This is just the implementation of a new Dialog that shows the welcoming message when the application starts + a feature to Do not show it again. I think this is the most straight forward implementation that we can handle perfectly with the current architecture of Dialogs.