With the overview abstracted, also merge prep_pull_mail_tags into
prep_pull_mail that can handle both cases depending on the tags passed
as parameters.

We've had tons of fun in the past with -nightly merge commits, e.g.

commit e47410aa
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Sep 8 08:52:41 2014 +0200

    dim: cope better with silent conflict fixup patches

Now another kind of fun showed up, namely when a merge is just a
fast-forward without any content changes. That lead to the git diff
--cached check failing, which lead to not committing the merge, which
lead to to all subsequent merges failing too.

Since this is all too fragile rework the logic a bit and first filter
out the fast-forward merges. With those handled we know that there
will be a real merge and so always something to commit. Which also
means that we'll never have fun again with fixup patches getting lost.
Hopefully.

This has the added benefit of not calling dim script again.

dim pull-request-topic gets renamed pull-request as the generic
pull-request command, and the old dim pull-request for features becomes
pull-request-next.

Basically rewrite the documentation highlighting the similarities and
differencies between the commands.

Now we have all pull requests handled neatly in one place.

Realize that it's more of the same, really.

Similar to pull-request-fixes and pull-request.

For reuse.

This reverts commit 614869a7.

It makes things too ugly. We can return to this if we can come up with
neater ways.

It's still a lot of manual work and every time I need to check again
how the fixup patch naming scheme works.

Makes the setup process slightly more helpful.

Refer to the main maintainer repo for objects to save bandwidth and
nerves.

Require all referenced variables to have been set.

- quilt patches can be listed with the git forwarding using qf branch
- bash completion is done
- qf pull is done

Similar to git fetch + git merge @{upstream}

v2: Also support --rebase, like git pull --rebase. Also don't forget
bash completion.

Suggested by Jani.

Almost ended up tagging a random local wip branch ...

Also make it a bit more informative

Add support for checking a given range of commits using dim check-patch
instead of just one.

Without arguments to 'dim check-patch', the topmost commit (i.e. HEAD)
is checked like before. With a single commit-ish, 'dim check-patch
commit-ish' will check a range of commits commit-ish..HEAD instead of
just commit-ish like before. Finally, with a range expression 'dim
check-patch commit-ish..commit-ish' the given range is checked.

Use a local var for the commit for clarity. Print oneline commit summary
before the output. Use checkpatch.pl -q option to reduce output. Reduce
newlines printed for errors and warnings. Return 1 instead of exit 1 on
errors so we can continue as needed.

All of this is to better support other uses for dim_checkpatch in follow
up work.

The current approach has a bunch of problems:
- It relies on the local maintainer's latest upstream version tags, so
  can flip-flop if they don't match.
- It's not really precise around the merge window.

The new approach should work a bit better:
- Unconditionally push -fixes.
- For the for-linux-next branch either push dinf or dinq. If dinf is ahead
  of -fixes then push dinf, assuming that drm-next is frozen already and
  that we've accumulated fixup patches already. If -fixes is ahead of dinf
  then push dinq assuming that the merge window has closed already.

This means we need to refine our process a bit to make sure this works
correctly:
- Only push -fixes forward to the new release past -rc1. Use dinf for fixup
  patches while the merge window is still open.
- As soon as -fixes has overtaken dinf don't roll it forward until drm-next
  is frozen for the next merge window.

v2: Run this in -nightly instead of -rerere

Mostly copypasta

With rebase -i the default upstream is the remote branch, so no need
to specify that explicitly.

Don't jump back and forth depending on the TZ of the committer.

<j4ni> uuugh

This only uploads to private fdo repos, so not terribly useful in dim.
I've moved it all into my own scripts (and extended to also upload igt
docs) a long time ago anyway.

So let's rip it out.

Use un-annotated tags for such tags which will only contain the
oddball high-prio fixup patch.

We should tie the remote fetch, dim setup, and nightly.conf together
somehow.

required when doing fixups/merges on top of plain drm-intel-next.

git still hates me - we need to find the old tag for -next pulls,
since there won't be any with the current date.

We probably should put this into nightly.conf too somehow.