Fix --no-push related issues in --continue and --abort

[Jackenmen]

Fixes #41, fixes #42

[Jackenmen]

Right now this adds an already_committed to git config store to indicate whether the user is doing cherry_picker --continue after cherry_picker --no-push ... or after a cherry_picker ... that resulted in a conflict BUT I'm considering whether I won't change this to also support people doing manual git commit after resolving conflicts as mentioned here.

I'll check whether I could update the logic to just check whether there was already a commit made or not and post an update here once I do.

If one of the maintainers sees this before I get to it, does cherry-picker currently support commit ranges? This comment suggests that it does but this does not appear to be documented anywhere so I'm wondering whether I need to worry about supporting that too.

[Jackenmen]

I'm considering whether I won't change this to also support people doing manual git commit after resolving conflicts as mentioned here.

I updated the logic to support this. Now, if there is exactly one commit in the backport branch, it has its commit message amended and otherwise, cherry_picker makes a new commit on its own.