magit-show-or-scroll: Fix broken scroll

Commit df45a4d7eb broke scrolling for commits and stashes because it
used raw `magit-*-buffer-name-format' values for the buffers.
Merge pull request #1367 from kyleam/fix-magit-scroll

magit-show-or-scroll: Fix broken scroll
magit-stage: Fix staging of deleted files

Add '-u' flag so that deleted files can be staged.
Merge pull request #1368 from kyleam/fix-deleted-staging

magit-stage: Fix staging of deleted files
prevent crazy point adjustment

Under a seemingly harmless condition, set `disable-point-adjustment' to
t using `post-command-hook' to prevent the event loop's usually helpful
point adjustment from going berserk.  The following was also added as a
comment:

  So we ended up at the beginning of a section, which also is
  the end of the preceding sibling section, if any.  There are
  two markers here.  If the preceding section is hidden, then
  we are also at the end of an invisible text range.  So far
  so good.

  But if we ended up here because we moved upward (but not when
  moving downward), then "point adjustment" messes up badly.
  Visually point would still be in the right spot but according
  to the function `point' we would be somewhere else; at the
  beginning of the preceding section, which isn't even the
  first position "at the other end of the invisible text".
  The existence of markers appears relevant, but not their
  insertion types.  Wtf!

  If we are not at the start of a section then do not disable
  "point adjustment", because when we truely end up *inside*
  an invisible range, then moving outside is a good thing.
Revert "Package-Requires: add emacs-23.2"

This reverts commit 3f2f81b347bff884ad4759ed4c8b12c204ce75e0.

No version of `package.el' which works with Emacs 23.x
understands the "emacs" virtual package.  See issue #1369.
respect default-directory when creating and following xrefs
Declare debug information for some macros.
create and follow xrefs in log buffers too

Only do so in `magit-log-mode' and `magit-reflog-mode'
buffers; in `magit-log-select-mode' buffers don't do so.
Merge pull request #1370 from vanicat/t/declare-debug

Declare debug information for some macros.
Merge branch 'master' into next

Conflicts:
	magit.el
magit-read-gpg-secret-key: don't require match

Let the user exit with any input.  This allows selecting a subkey,
even though we don't offer such keys for completion.
Merge branch 'master' into next

Conflicts:
	magit.el
save modified file-visiting buffers more often

Previously we did save, or offer to save such buffers when:

* Before refreshing (g) the status buffer.  (Which also happens when
  refreshing some other Magit buffer, but unfortunately at the wrong
  time; after updating the other buffer.)
* Before creating or jumping to the status buffer (C-x g).
* Before creating and/or checking out a branch.

Now we do so when:

* Before refreshing any Magit buffer.
* Before creating or jumping to any Magit buffer.
* Before calling git in `magit-call-git' and `magit-start-git',
  which means that we do so for many more Magit commands, which
  end up running Git using one of these functions.

This is controlled using the following new hooks:

* magit-mode-setup-hook
* magit-pre-refresh-hook
* magit-pre-call-git-hook
* magit-pre-start-git-hook
Merge branch 'n/save-buffers' into next
magit-stash-drop: offer to delete all stashes in region
fix magit-push-tags
magit-diff-highlight-whitespace: use lazy match
Lazy match should be used to find trailing spaces.
Merge pull request #1373 from shigi/trailing-spaces

magit-diff-highlight-whitespace: use lazy match
magit-git-executable: except on windows, use just the name

Since f0186c88732e543d9487082405685fa0a2688b70 `magit-git-executable'
was set to the full path to the executable, which becomes problematic
when connecting to a remote repository using Tramp and the executable
is not installed in the identical location on that system.

On Windows keep using the full path, because here multiple "git.***"
are installed and it makes a big difference which is used.  I would
much rather have a handful of Windows users report that they cannot
use Magit remotely than to have many more users complain that "Magit
is nice, but soooooooo slow on Windows".

We could use different variable for local and tramp Git, I suppose.
But the proper way of testing that is `file-remote-p', and that is
to expensive to run over and over again.  And I don't like caching.