don't repeatedly refresh when evaluating magit.el

Or any other library that uses `magit-set-variable-and-refresh'
or `magit-set-default-diff-options' to set an option.
magit-describe-item: move definition

Move the definition of `magit-describe-item' to the new "Maintenance
Tools" subsection of toplevel "Miscellaneous".  This new section will
soon contain more such things.

Rename the subsection of "Acting" where `magit-describe-item' from, from
"Describe" to "Kill".  The name previously was wrong because it also
contained and still does, the unrelated `magit-copy-item-as-kill'.

Now that it has been mostly cleaned up, we should probably lose the
subsections of the second "Acting" section, and rename it to something
like "Item Commands".  But that's another issue.
loading magit.el now calls git-commit-auto-mode-enable

Loading `magit.el' now calls `git-commit-auto-mode-enable', unless
library `magit-log-edit' is on the `load-path', in which case that
is loaded instead.
magit-add-section-hook: new function

Add hook-manipulation function `magit-add-section-hook'.  It differs
from other such functions in that it allows inserting a new function
before or after an existing member of the hook list.

The intended use of this function are "buffer section hooks".  All
"buffer refreshers" have been using a hook to insert sections, for a
while now.  These hooks work great for user customization, but until
now modes that that need to insert additional sections (and that only
for some repositories) the old hook implementation still had to be
used.

This commit completes the new implementation the missing piece, the
specialize `add-hook' function.  The next commit will start using that
in all minor modes.  And the one after that will remove the old one.
magit-svn-mode: use magit-add-section-hook
magit-stgit-mode: use magit-add-section-hook
magit-topgit-mode: use magit-add-section-hook
magit-define-inserter: remove macro

Remove the macro `magit-define-inserter' which, until two commits ago,
had to be used to create functions that insert sections.  It now isn't
necessary anymore that each such function runs two hooks.
Merge branch 'pr/section-hooks'
magit-create-branch-hook: new hook variable

In `magit-create-branch' explicitly run the new (but unadvertised) hook
`magit-create-branch-hook'.  This is a replacement for the automatically
run `magit-create-branch-command-hook'.  The latter will be removed soon.
magit-remote-update-hook: new hook variable

In `magit-remote-update' explicitly run the new (but unadvertised) hook
`magit-remote-update-hook'.  This is a replacement for the automatically
run `magit-remote-update-command-hook'.  The latter will be removed soon.
magit-pull-hook: new hook variable

In `magit-pull' explicitly run the new (but unadvertised) hook
`magit-pull-hook'.  This is a replacement for the automatically
run `magit-pull-command-hook'.  The latter will be removed soon.
magit-push-hook: new hook variable

In `magit-push' explicitly run the new (but unadvertised) hook
`magit-push-hook'.  This is a replacement for the automatically
run `magit-push-command-hook'.  The latter will be removed soon.
magit-define-command: remove macro
Merge branch 'pr/just-defun'
Fix marker positions of section in branch manager
Merge branch 'pr/fix-section-marker-positions'
magit-{,key-mode-popup-}apply-mailbox: new key binding

In `magit-mode-map' bind "J" instead of "j" to
`magit-key-mode-popup-apply-mailbox' (or `magit-apply-mailbox' if
`magit-rigid-key-binding' is non-nil).  In the apply-mailbox popup
keymap bind "J" accordingly.
magit-uninteresting-refs: improve regexps

* Anchor all regexps.
* We are not interested in submatches.
* Put each regexp on its own line; this list will grow.
magit-uninteresting-refs: always ignore topgit refs

Add the regexps that cause the topgit "top-base" refs to be ignored to
the definition of `magit-interesting-refs' instead of adding them only
when `magit-topgit-mode' is turned on.

I guess it could happen that someone does not use topgit and uses
"refs/top-bases" and "refs/remotes/REMOTE/top-bases" for something else,
but I think it that is rather unlikely.  If it does happen, that user
can just remove the respective regexps from the variable - which by the
way will get easier once it is a customizable option.