…d launch

We refactor the `BackendProcess` class to have specific methods that the main process can use to orchestrate launching the backend app
Because we can only emit events to the renderer process in the main process (so no way to emit them in `BackendProcess`, unless we pass the `mainWindow` down to the `BackendProcess` class) this exposes a bunch of launching functionality to the main process (it was previously all hidden in the `backendProcess.maybeStartup()` function)

In future refactors, am definitely open to pushing `mainWindow` down to `BackendProcess` and dealing with all aspects down there. However, as a first iteration I think this is fine.

The logic for this the start up goes like this:
- if a backend process is already running, error. Catch the error & send a message to the renderer that a qri backend is already running
- check if we have a compatible backend version. If it's too low, send a message to the renderer that the version is incompatible
- check if we need a migration - if we do, send a message to the renderer that we are migrating
- launch the backend

- add `BootupComponentType`
- `state.ui.bootupComponet` defaults to 'loading'
- add `UI_SET_BOOTUP_COMPONENT` action type
- add `setBootstrapComponent` action
- add `selectBootstrapComponent` selector

Both the renderer process and main process need to be on before we can successfully coordinate behavior.

`App` component now emits an `app-fully-loaded` event.

Moved the backend launching process into the ipcMain `app-fully-loaded` event handler. This also means that whenever the app re-loads, we check for a backend connection, and if we don't find one we launch again. Which I think is a nice pick up!

Downside is we get slightly longer loading time in dev mode (since it takes a bit to compile the app), but no discernible changes in prod mode!

now that the backend flags/expectations have changed, we can run any comand to see if it exits with code `2` (which indicates that a migration is needed)

…onfig` as migration check