Improve error reporting on config migration

[kas2020-commits]

• PR Description

closes #4209

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[kas2020-commits]

I hope I'm not bothering with this small change I just want to save someone from an annoying debugging session in the future that I went through. Feel free to change the strings to your liking if you don't like the messages.

[stefanhaller]

The logging is a little bit on the verbose side now for my taste, but if it helps, I'm ok with it.

I wonder if we can do better though:

• it would be nice to report which config settings were migrated, so that users can fix their config file manually if they want to
• I'm actually wondering if we need to abort at all when rewriting the config fails. We could just report the error (in some way) and then continue launching. After all, the config was migrated properly in memory, so running lazygit should behave correctly at that point; the worst that happens is that there is a slight delay every time they start lazygit, because the config needs to be migrated again every time. But I'm not even sure this would be noticeable.

These could be done in separate PRs of course (if we find them important enough), I'm happy to merge this one as is. Tagging @jesseduffield in case he has more thoughts.

[jesseduffield]

@stefanhaller I agree, those suggestions sound good. This PR also LGTM. I don't mind the verbosity because this will only happen after upgrading lazygit

[stefanhaller]

@kas2020-commits CI reported two problems: a spelling error (fixed by 5e1c23b) and an actual behavior error (fixed by ddd682e). Did you even test the feature? I don't think the success reporting would have worked. (I didn't test it myself.)

[kas2020-commits]

@stefanhaller my bad, I wrote the patch online without double-checking the fmt.Println sig (not a go dev)

[stefanhaller]

my bad, I wrote the patch online

Oh, ok. I usually trust people to have run their code at least once to see if it even does what they want. Good to know that I can't count on that.

Tested it myself now, seems to work. Thanks for the contribution.