Import: Use absurd `git apply' emulation if gbp pq import fails

Import: Use absurd `git apply' emulation if gbp pq import fails

gbp import can fail due to git apply not understanding patches.
This is #841867 (against dgit).

The underlying problem is #841866 (in gbp pq) which exposes things
like #841865 and #829067 (in git).  I imagine there are other lurking
incompatibilities between git-apply and dpkg-source.

We could in principle reimplement the gbp patch metadata extraction.
But that would be quite tiresome and have its own compatibility
problems.

The real problem is just `git apply'.  (Indeed gbp already tries git
apply without, and then with, a whitespace fix option.)  We work
around the trouble by providing our own implementation of `git apply'.

Specifically:

We try to do things the sane way (just running gbp pq import) first.
If that works, great.  If it doesn't, we put /usr/share/dgit/absurd on
the PATH.  That contains only a sh script called `git'.  This sh
script figures out whether the caller is trying to invoke `git apply'.
If not, it runs the real git.

If the caller wanted git-apply, the absurd git script emulates it
using dpkg-source --before-build.  Conveniently, we know that the
series file will not be touched by patches.  So we can write just the
patch we care about into the series file, and run --before-build,
which applies just that one patch.

The results are committed (minus the .pc), and for the next patch,
dpkg-source sees again a tree with simply a single patch to apply.

We try ordinary gbp pq first because our absurd approach is very slow
on a big tree.  Also we would like to maximise our chances of the
import working.  If git and/or gbp ever work better by themselves, all
of this craziness will simply not happen.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>