When the blame window is closed, ensure the wrap setting is restored.

Not sure where `l:wrap` came from, maybe just an oversight on my part.

Don't change the author for moved lines.

When the `<Enter>` key is pressed in the GitBlamer window, run
`!git show` on the commit from the current cursor line of the blame.

This allows a changed line to be inspected in the context of its
original changeset. It also saves me time from my previous workflow:

    cpe^Zgit show <Apple-P><Enter>

Previously, when the GitBlamer window was closed, the window it was
opened from would not be re-focused. Because of this, you couldn't just
pick up where you left off, you had to run a window command first.

This change re-focuses the original window automatically, bringing you
right where you were before opening GitBlamer.

Unfortunately, this seemingly simple want is not easy to do in VimL.
There's a `WinLeave` autocmd, but that event gets executed _before_
leaving a window. Similarly, the `BufWinLeave` autocmd we already had
gets executed before the buffer is removed from the window. Because
these events happen before the window is left, running the `wincmd w`
command doesn't work. We need a way to run the command after the window
is closed, allowing us to work with the new window layout and window
numbers.

In order to run `wincmd w` at the proper time, we add a new autocmd upon
closing the GitBlamer window that gets executed when any window is
entered. That autocmd refocuses the correct window and removes itself,
having served its purpose.

I used a tab variable to store the window number because it was a way to
allow multiple GitBlamer instances in different tabs. Otherwise, the
autocmd would be attached to a window that isn't correct in other tabs.
Also, augroups can't have dynamic names, so we can't create them
programmatically, preventing us from having multiple autocmds with
different window numbers for different tabs. The disadvantage of using a
tab variable is that window focus restoration doesn't work when multiple
GitBlamers are opened in a single tab.

If `nowrap` is set, the plugin causes an error because it tries to
concatenate the `restore` variable which hasn't been defined. Define the
variable outside the `if &l:wrap` condition to ensure it's available for
concatenation.

In order to get the cursor lines to correctly match up horizontally in
all cases, set 'nowrap' on the buffer.

To set 'wrap' back, follow fugitive.vim's example:
https://github.com/tpope/vim-fugitive/blob/f3ccb0c12ee4985b8808f83059830a24cc92821c/plugin/fugitive.vim#L2038-L2040

Makes it just a bit easier to close the GitBlamer window. Since we
shouldn't need macros in this panel it should be fine.

Adding `syncbind` appears to fix the bug where in certain cases the
GitBlamer cursor line and the buffer cursor line weren't horizontally
aligned.

Use the `cursor()` function to set the position of the cursor. This call
is simpler than `setpos()`, and more descriptive than `execute
l:top_line` (that was inspired by fugitive.vim,
https://github.com/tpope/vim-fugitive/blob/f3ccb0c12ee4985b8808f83059830a24cc92821c/plugin/fugitive.vim#L2048-L2064)

Take the mechanism that Fugitive.vim uses:
https://github.com/tpope/vim-fugitive/blob/f3ccb0c12ee4985b8808f83059830a24cc92821c/plugin/fugitive.vim#L2048-L2064

This positions the cursor lines on the same horizontal line so that
blame information can be read on the same line as the code it
corresponds to.

Not sure, but it doesn't seem to work exactly right on one of my
machines, but did appear to work correctly on another. Could just be the
fault of 'wrap' though.