make reading passwords customizable

We use a process filter to detect when git or one of its subprocesses
(in many cases ssh) prompts the user for usernames, passwords and
passphrases.  Until now the prompt strings we were able to detect were
hardcoded.

Add new options magit-process-{username,password}-prompts so that users
can easily tell magit to forward the (sometimes quite unique) prompts
their setup spits out, without having to patiently having to wait for us
maintainers to agree, to support them.
magit-process-{username,password}-prompts: pimp regexps
forward git/ssh yes-or-no prompts to the user
Merge branch 'prompt'
remove magit-bug-report

I do not think having such a function is useless per se but in its
current form it is.

1. I have never actually seen a bug report that looked that it was based
   on the contents of buffer created by it.

2. It was only used in very few places and it appears these places never
   actually cause any errors.  (Actually in the case of `magit-run*'
   errors are less unlikely).

3. For this function to be useful it would have to be used everywhere
   errors can happen.  Doing so would be way to ugly without first
   converting it to a macro and then some.

4. Just writing some versions strings into a buffer and telling the user
   to do something is not particularly useful.  Something using Message
   mode might be, though.

So yes, maybe I will add back something similar, but it has to be
redesigned to be useful at all.  And there are more important things to
do first.
update modeline inside `magit-revert-buffer'

We have a mechanism for "updating buffers that need it": the refresh
mechanism implemented by the `magit-refresh-*' functions and macros.

Refreshing the modeline on behalf of vc did not make use of that but
instead relied on `magit-update-vc-modeline' being called explicitly.
Now it is refreshed whenever the regular refresh mechanism kicks in,
which can both positive or negative.

Positive because we don't have to identify each place where updating
the modeline would make sense; negative because it is a potentially
costly operation which is now done under circumstances that do not
necessarily call for it.

I will take care of the drawbacks by making this both less costly as
well as optional all together, in later commits.  (This commit already
makes refreshing slightly more efficient because it removes one looping
of the list of buffers.)

The name of this function now doesn't match all it does anymore.
That will also be taken care of.
magit-refresh-wrapper: cosmetics
only call dired-uncache when needed

When dired isn't loaded then there is no information to be uncashed.
Don't load dired just to unload a cache that doesn't even exist.
add magit-refresh-file-buffer-hook

Call it in `magit-refresh-wrapper' for every buffer visiting a file in
the current buffer.

Bring back `magit-update-vc-modeline' as a wrapper around
`vc-find-file-hook' to update _a single_ buffer.  Do _not_ add it to the
hook's default value.  I don't expect many people to pay attention to
the Vc controlled part of the modeline (and if they do they will notice
and can add it themselves).  On the other hand many people complain
about bad performance and not using this function does improve that.
See issue #573.  We should implement our own "status in modeline" hook
function, see issue #240.

Add new function `magit-revert-buffer' to the hook.  It does the same
thing as the now removed `magit-revert-buffers' (plural) did until a
four commits ago - just for a single buffer.
Merge branch 'refresh'
magit.texi: remove FAQ 2.1; it's wrong

A proper fix for the "How do I fix international characters display?"
will hopefully be written soon.  Regardless the answer that was provided
was not correct or at least insufficient.
magit-read-file-from-rev: fix regression
create magit-log-edit.el from existing code

Create new library `magit-log-edit.el' from code that was previously
part of `magit.el'.  Due to how the involved libraries depend on one
another some functions have to be declared in `magit.el' for the time
being.

The moved code isn't modified, except that it is reordered and split
into sections.
rename to magit-log-edit-prev-window-configuration

from `magit-pre-log-edit-window-configuration',
because it should have a `magit-log-edit-' prefix.
rename to magit-log-edit-status-buffer

from magit-buffer-internal (?!).
magit-log-edit-mode-map: reorder bindings

This makes it a better (implicit) index of the command
definitions in the section that contains it.
Merge branch 'separate-log-edit-mode'
magit-edit-log.el: define keymap before mode

Otherwise the variable would already be bound once the
defvar is evaluated causing it not to do anything.
merge toplevel sections "Acting (1)" and "Acting (2)"

Until recently the toplevel section "Log Edit Mode" was between these
two sections, but that was moved to a separate file.

To merge these two sections another toplevel that was between the two
had to be made a subsection.  In the process that section "ChangeLog"
was renamed to "Commit".  In the future it will also contain a command
`magit-commit', which will be a wrapper around `magit-log-edit' or the
respective function from `git-commit-mode'.
allow using magit-add-log during rebase

Like `magit-log-edit' this function detected an progress rebase and
offered to continue that instead of committing.  When the user reply
was "no" this function acted as if that means "no I want to do
anything at all".  `magit-log-edit' already understands it correctly
"no thanks, I really do want to commit".

Change this function to behave the same way.  Because this function
used `magit-log-edit' internally the test for an in-progress rebase
can be removed here.  There is some code before the call to
`magit-log-edit' but that only collects some information, has no side
effects, and is inexpensive.