Before we can tweak the revwalk to be more efficent when negotiating,
we need to add an "insertion mode" option. Since there's already an implicit
set of those, make it visible, at least privately.

As part of reducing our divergence from git, its code for revwalk was ported
into our codebase. A detail about when to limit the list was lost and we ended
up always calling that code.

Limiting the list means performing the walk and creating the final list of
commits to be output during the preparation stage. This is unavoidable when
sorting and when there are negative refs.

We did this even when asked for unsorted output with no negative refs, which you
might do to retrieve something like the "last 10 commits on HEAD" for a
nominally unsorted meaning of "last".

This commit adds and sets a flag indicating when we do need to limit the list,
letting us avoid doing so when we can. The previously mentioned query thus no
longer loads the entire history of the project during the prepare stage, but
loads it iteratively during the walk.

Next to including several files, our "common.h" header also declares
various macros which are then used throughout the project. As such, we
have to make sure to always include this file first in all
implementation files. Otherwise, we might encounter problems or even
silent behavioural differences due to macros or defines not being
defined as they should be. So in fact, our header and implementation
files should make sure to always include "common.h" first.

This commit does so by establishing a common include pattern. Header
files inside of "src" will now always include "common.h" as its first
other file, separated by a newline from all the other includes to make
it stand out as special. There are two cases for the implementation
files. If they do have a matching header file, they will always include
this one first, leading to "common.h" being transitively included as
first file. If they do not have a matching header file, they instead
include "common.h" as first file themselves.

This fixes the outlined problems and will become our standard practice
for header and source files inside of the "src/" from now on.

Keep the definitions in the headers, while putting the declarations in
the C files. Putting the function definitions in headers causes
them to be duplicated if you include two headers with them.

Without this change, compiling with gcc and pedantic generates warning:
ISO C does not allow extra ‘;’ outside of a function.

If there have been no pushes, we can immediately return ITEROVER. If
there have been no hides, we must not run the uninteresting pre-mark
phase, as we do not want to hide anything and this would simply cause us
to spend time loading objects.

The old separation was due to the old merge-base finding, so it's no
longer necessary.