feat: new list

[caarlos0]

No description provided.

[Dieterbe]

Not sure if this is still maintained, and i hope to hear from @caarlos0 about this PR,
but as an outsider looking at the code, and trying it out, it looks pretty good to me and just needs a bit more work.

It seems what is happening in this PR is:

1. switch from using multiple models (with each their own event loop), to a single model, backed by a generic list library (https://pkg.go.dev/github.com/charmbracelet/bubbles/list), which seems much cleaner and better, and is more full-featured (e.g. we now have free pagination and could easily add filtering)
2. resizing window now shows ellipsis at cutoff, however it has other rendering bugs, similar to Display issues when more than one screen #67, but Display issues when more than one screen #67 itself is fixed. it seems that if you have many more entries than your screen height can fit, it all works and renders fine (with pagination), but it does get messed up when you resize the screen.
3. some dependencies were updated

main:
this PR:

I do see 2 potential issues with this PR:

1. due to a change in the Github API, it needs this tweak:

diff --git a/fork-cleaner.go b/fork-cleaner.go
index e094f60..5da6f52 100644
--- a/fork-cleaner.go
+++ b/fork-cleaner.go
@@ -78,6 +78,7 @@ func FindAllForks(
 			parent.GetName(),
 			parent.GetDefaultBranch(),
 			fmt.Sprintf("%s:%s", login, repo.GetDefaultBranch()),
+			&github.ListOptions{}, // note: without pagination, we are limited to 250 commits. but that's enough to get an idea
 		)
 		if err != nil {
 			return forks, fmt.Errorf("failed to compare repository with upstream: %s: %w", repo.GetFullName(), err)

2. seems the Update() event loop can generate multiple commands which will execute concurrently
   and may race for access to the same structures?

@caarlos0 : does the above make sense? I would suggest to get this PR merged soon, as it is a fairly invasive change to the core of the app. I could tackle the 2 listed shortcomings, but the rendering is above my head (but i don't think that issue should block merging)

[caarlos0]

yes, things happen and I ended up no finishing this one... will try to revive it

[caarlos0]

hey @Dieterbe thanks for the comments

1. yes, donee
2. in theory, no, as we don't act on a pointer to the model, and return another model every time update runs... unless I'm somewhere changing it directly, if you see that please let me know...

in any case, will merge this, feel free to take a look if you want 🙏

thank you!