Allow rewording in interactive rebase

**Is your feature request related to a problem? Please describe.**
We do not currently allow arbitrary commits to be marked for re-wording as part of an interactive rebase.

**Describe the solution you'd like**
A child lazygit process will be invoked by git to determine the content of a commit message, and it will talk to the parent lazygit process to get the new commit message from the user (via a prompt panel).

The parent lazygit process will choose a random TCP port to listen on and will serve requests to that port. When invoking `git rebase`, the parent process will pass some extra env vars:
* `GIT_EDITOR=`
* `LAZYGIT_DAEMON_KIND=editor`
* `LAZYGIT_PORT=`

If you look in `pkg/app/daemon/daemon.go` you'll see we have some precedent for running lazygit as a `daemon` i.e. a separate process from the parent gui process. In this case we'll be using lazygit as our GIT_EDITOR and when lazygit starts with `LAZYGIT_DAEMON_KIND=editor` it will use an RPC request to the parent lazygit (using LAZYGIT_PORT) passing the path of the file that needs to be edited (i.e. `.git/COMMIT_EDITMSG`). The child process will block until it gets the response from the parent process. The parent process will prompt the user to edit the message and afterwards, will send a response to the child process.

**Additional context**
We did some [similar work](https://github.com/jesseduffield/lazygit/pull/372) for this a while back when thinking up ways to get lazygit to handle credential prompts from git (by setting GIT_ASKPASS=) but we ended up parking that work as we had security concerns. By contrast, this feature shouldn't have any security concerns given you'll only be editing commit messages.

One tricky question is: how do we know if the user wants to edit the message from within lazygit or from within an editor? Some options:
* have a way of jumping from the prompt panel to an external editor via some keybinding
* assume the user wants to use the within-lazygit prompt panel
* allow the config file to specify what should happen.

I'm leaning towards the second option just because it's easier to implement for the sake of this initial feature.