rename magit-insert-{ => topgit-}topics

Looking at the name should be enough to know this is from an extension.
Also rename the name of the section from just `topics' to `stgit-topics'.
rename magit-{svn-insert => insert-svn}-{status- => }remote-line

For consistency with other such inserters in magit.el switch "svn" and
"insert".  Also remove the "status-" part.  While this is intended for
use in status buffer, that is not mean we need to keep that part.
Actually it should also be removed for some other inserters that contain
it, since they can be used outside the status buffer.
Merge branch 'section-cleanup'
`magit-insert-status-remote-line': define using `magit-define-inserter'

Among other things, commit f6506846 renamed `magit-svn-remote-string'
to `magit-svn-insert-status-remote-line', and added it to
`magit-after-insert-remote-line-hook', intending for it to run after
`magit-insert-status-remote-line'.

However, this could never work, since `magit-insert-status-remote-line'
wasn't defined using `magit-define-inserter' meaning the hook wouldn't exist,
and even if did, it would be called `magit-after-insert-STATUS-remote-line-hook'.

As a result, `magit-svn-mode` no longer displayed the "Remote:" line.

I would have liked to drop the "status" part in `magit-insert-status-remote-line'
(see commit 44abd449), but then I'd have to satisfy my urge to make the same
change(s) in *all* the inserter functions, thereby tainting this branch with
commits that don't belong, so I've opted to adjust `magit-svn-mode' instead.

Choices, choices...

Fixes #924.

Signed-off-by: Pieter Praet <pieter@praet.org>
`magit-insert-svn-{unpulled,unpushed}': pass STYLE arg to `magit-wash-log'

Commit 4966a044 altered `magit-parse-log-line' to no longer set STYLE
if it was nil, because `magit-wash-log' is now supposed to always pass
it an appropriate value (via `magit-wash-log-line').

`magit-insert-svn-{unpulled,unpushed}' weren't updated accordingly though,
causing `magit-svn-mode` to fail with `wrong-number-of-arguments` when
there are unpulled/unpushed commits.

Fixes #925.

Signed-off-by: Pieter Praet <pieter@praet.org>
magit.el: add "Compatibility/Emacs" (sub)section headers

Signed-off-by: Pieter Praet <pieter@praet.org>
magit.el: restore code provenance statement

Commit 445e6e8d moved the Emacs compatibility functions from
"magit-compat.el" into "magit.el" but dropped the headers,
thereby losing the code provenance statement.

Signed-off-by: Pieter Praet <pieter@praet.org>
magit.el: restore compatibility statement

Commit 445e6e8d moved the Emacs compatibility functions from
"magit-compat.el" into "magit.el" but dropped the headers,
thereby losing the compatibility statement.

Signed-off-by: Pieter Praet <pieter@praet.org>
magit.el: clean up compatibility statement

Signed-off-by: Pieter Praet <pieter@praet.org>
magit.el: fix Emacs compat function versions

Specify in which commits the functions were added to Emacs, and correct
the version numbers for `string-prefix-p' and `string-match-p'.

Note that we try to ensure compatibility with Emacs 23.2 and up, so the
compatibility functions for `string-prefix-p' (added in 23.2 instead of
23.3) and `string-match-p' (added in Emacs 23.1 instead of 23.3) are
nothing but clutter, meaning we should probably sacrifice them to Lord
Lambda so we can recycle the parens.

Signed-off-by: Pieter Praet <pieter@praet.org>
`magit-refresh-commit-buffer': pass REV *after* options

Strictly speaking, we can pass the REV in between the options
without causing any trouble, but that doesn't mean we should...

Signed-off-by: Pieter Praet <pieter@praet.org>
`magit-format-commit': pass REV *after* options

Strictly speaking, we can pass the REV in between the options
without causing any trouble, but that doesn't mean we should...

Signed-off-by: Pieter Praet <pieter@praet.org>
`magit-key-mode-add-option': rename to `magit-key-mode-toggle-option'

Because it *toggles* instead of *adding* OPTION-NAME.

Signed-off-by: Pieter Praet <pieter@praet.org>
`magit-merge': update docstring

See commit 6fcac6c5.

Signed-off-by: Pieter Praet <pieter@praet.org>
`magit-merge-check-clean': optimize

Check `magit-merge-warn-dirty-worktree' *before* `magit-everything-clean-p'.

Evaluating a variable is much cheaper than making two calls to `git-diff(1)',
so do that first instead of wasting cycles only to find out we weren't planning
on asking for confirmation anyway.

Signed-off-by: Pieter Praet <pieter@praet.org>
`magit-rename-branch': use old name as initial input for new name

When renaming branches, one often wants to change only a small portion
of the name (e.g. removing a prefix like "wip/"), so when asking for the
new name, use the old name as initial input instead of making us type
the whole branch name again.

Signed-off-by: Pieter Praet <pieter@praet.org>
`magit-rename-branch': do some error checking

Avoid needlessly calling `git-branch(1)` with arguments which
are known to be invalid/pointless.

Signed-off-by: Pieter Praet <pieter@praet.org>
`magit-rename-remote': use old name as initial input for new name

When renaming remotes, one often wants to change only a small portion
of the name (e.g. to correct a typo), so when asking for the new name,
use the old name as initial input instead of making us type the whole
remote name again.

Signed-off-by: Pieter Praet <pieter@praet.org>
`magit-ref-ambiguous-p': use `magit-git-success'

Since commit f8d304a1, `magit-ref-ambiguous-p' always returned nil.

Instead of depending on how one of our functions behaves when presented
with `git-rev-parse(1)'s error messages, just check its exit code...

Signed-off-by: Pieter Praet <pieter@praet.org>
`magit-rename-remote': do some error checking

Avoid needlessly calling `git-remote(1) rename` with arguments which
are known to be invalid/pointless.

Signed-off-by: Pieter Praet <pieter@praet.org>