Discussion: Redundant use of goroutines in prompts and more

Currently, as raised in the latest meet, a lot of functions in `prompt.go` use goroutines when there seems to be no apparent reason to use them.
Another key takeaway from this by me was that currently, while an API request takes too long, or timeouts or something, we dont show the TUI at all.
The TUI shows only _after_ the api call has proceeded.

I would like to suggest a change to this method, and utilize the `Init()` function in bubbletea to show a `Loading... or Requesting...` while the API carries out its request.

## Context on how Bubbletea works

Bubbletea has 2 goroutine types that work simultaneously,
1. Update Msg Loop: This is the loop that handles, distributes and executes Messages sent into the `Update()` function via an older `Update()` instance or the `Init()`.
2, The Cmd Handling: All the `tea.Cmd` handle themselves _asynchronously_ in seperate goroutines.

If we utilize the Cmd nicely we can make it truly asynchronous.

## Example

As some of you may know, I have an OSS project that is a TUI Container manager. In that I heavily rely on this asynchronosity (idk if thats a word). This is something I have made up after several iterations.

```go
var tickCmd = func() tea.Cmd {
return tea.Tick(time.Second*3, func(_ time.Time) tea.Msg {
return messages.MonitoringTick{}
})
}

func (s *Monitoring) Init() tea.Cmd {
return tea.Batch(tickCmd(),
func() tea.Msg {
m, err := runtimes.RuntimeSrv.RuntimeLogs(context.Background())
if err != nil {
return messages.ErrorMsg{Msg: err.Error()}
}
return messages.MonitoringMonitor{Monitor: m}
})
}
```

This is an implemented `tea.Model` in this I do all my logic inside the Init() function for async. From making goroutines (thats what RuntimeLogs does, to making a ticker)

You can take a look at more examples in this: github.com/cruise-org/cruise/tree/main/internal/models .

I suggest having a similar approach, if this is needed I can make up a proposal for how _harbor-cli _ can make use of this with less changes.

Current Ideology: I was thinking of passing functions to our models, like instead of calling the api we pass a function that calls the API. And then the `tea.Model` can call that inside the `Init()` function. While we show a default Loading or something