Add support for multi-file edits

[fab4100]

Git send-email by default uses multi-file edit mode (sendemail.multiEdit) when more than one patch file requires editing an associated email message and/or cover-letters. Multi edit mode spawns one editor instance with multiple files in argument list. This behavior is supported by creating multiple splits for a running vim instance when :G send-email is called. When the user sets sendemail.multiEdit to false in the local or global config, if multiple files need editing then they are processed sequentially in a single split at a time.

Closes #2352

[fab4100]

To help push progress, I am describing the changes introduced in this PR in more detail below.

1. Multiple file arguments are read by adding a for-loop that appends the arguments to the sentinel $FUGITIVE.edit (https://github.com/fab4100/vim-fugitive/blob/28f17e54691def71d5f0bf3aa448fe5bd68b70de/autoload/fugitive.vim#L3958)
2. Instead of reading a single file argument, a list of arguments is read (https://github.com/fab4100/vim-fugitive/blob/28f17e54691def71d5f0bf3aa448fe5bd68b70de/autoload/fugitive.vim#L3446) which are then processed in a newly added outer loop (https://github.com/fab4100/vim-fugitive/blob/28f17e54691def71d5f0bf3aa448fe5bd68b70de/autoload/fugitive.vim#L3448), each loop iteration initializes a new buffer with focus on the first file argument given upon loop exit (hence the reverse(files) iterator). Since now multiple buffers may be created, it is no longer sufficient to indicate buffer deletion by simply removing the sentinel ($FUGITIVE.edit). Instead, the number of active buffers is stored into the sentinel to keep track of the number of active buffers when multiple files are being edited (https://github.com/fab4100/vim-fugitive/blob/28f17e54691def71d5f0bf3aa448fe5bd68b70de/autoload/fugitive.vim#L3447).
3. Whenever a buffer is deleted, the active buffer count in the sentinel is decreased https://github.com/fab4100/vim-fugitive/blob/28f17e54691def71d5f0bf3aa448fe5bd68b70de/autoload/fugitive.vim#L3735-L3736. If the active buffer count is zero, the same code is executed as is currently the case for the single file only edit (deleting the sentinel then resume session https://github.com/fab4100/vim-fugitive/blob/28f17e54691def71d5f0bf3aa448fe5bd68b70de/autoload/fugitive.vim#L3739-L3740). If one or more buffers are active, the sentinel is updated and the session is resumed without deleting the sentinel (https://github.com/fab4100/vim-fugitive/blob/28f17e54691def71d5f0bf3aa448fe5bd68b70de/autoload/fugitive.vim#L3742-L3743).
4. The active buffer count is appended to the resume queue whose arguments are passed down s:RunWait which checks for the newly appended active buffer count argument (see previous item). If there are 1 or more active buffers, s:RunWait returns to caller without taking any action (continuing editing session of active buffers). If the active buffer count is zero the same code is executed as is currently done for the single file only implementation (which concludes the $FUGITIVE.edit session).

Please let me know if I can implement some changes you may desire. Thanks for taking the time.

[fab4100]

Hi Tim, I have rebased this branch onto latest master and addressed your comment regarding nosplitbelow and splitbelow here https://github.com/tpope/vim-fugitive/pull/2359#discussion_r2008787581. Active buffers (possibly multiple) are now handled in memory (contents in the sentinel file are not touched), see my comment here https://github.com/tpope/vim-fugitive/pull/2359#discussion_r2008788198. Please let me know your thoughts and whether we can proceed. Thanks!