debian/patches: Remove X-Dgit-Generated

I'm not going to use Dgit, but rather track all changes in a more
granular way. Remove the obsolete headers.

debian/rules: Add orig command

I copied this one from the linux team. It combines the orig file with
the packaging, so we can start using quilt to refresh the patches.

Move grub config into xen-utils-common

The grub config snippet is not arch dependent, neither version
dependent, so it has to move into a 'common' package.

The packages with a version number in their name only have contents that
do not conflict with a previous or next version. Having this file in the
version dependent xen-hypervisor package currently prevents us from
being able to co-install the current and next version of Xen.

So, I can do this here for new packages in unstable but that will only
fix upgrades from xen 4.9 to 4.10. The same change still needs to go
into a stable update to solve the problem for upgrades from Stretch to
Buster.

Also see https://bugs.debian.org/852545

debian/lib/python: Recognize pre / rc versions

    When tracking the latest upstream versions in Debian unstable, I'd
like to keep the packages updated with latest available security patches
which are available when working on a new upload. So that means not
always working with an exact tagged upstream release.

There are two possible approaches when doing this:

1. Use the latest official release as orig tar and keep the rest of the
changes in debian patches. This is also what we would do for security
updates to stable.
2. Just follow the upstream stable branch lines (they will always fix
forward) and keep the latest changes in the orig tar.

I think option 2 makes the most sense for uploads to unstable when we're
nowhere near to a freeze yet. This results in version numbers like
4.9.2~pre+1.32e364c4e7-1, where the 1 is simply a helper because git
commit ids are not sortable. 4.9.1+1.32e364c4e7-1 would also be an
option, but since xen will report itself als 4.9.2-pre (e.g. in xen info
output), I prefer the ~pre one.

    When testing new versions that are in rc state upstream, we might
put them in the Debian experimental distribution, so that we can find
out what needs to be done to the packaging already, and so that we
provide the opportunity for Debian users to help testing the new release
on their hardware.

These versions will usually look like e.g. 4.10~rc8-1~exp1, but
incidentally they could also include a few newer corrections, in which
case we end up with a git revision again, like seen above, but then with
rcX instead of pre and now the second pattern choice, because upstream
doesn't let us know if there will be a next rc, or the actual release.
So, that would be something like 4.10~rc8+1.3e11e302a8-1~exp1

    This change allows both of these version patterns. While only the
major.minor version is used from it all, it's a nice sanity checker to
prevent eventual mistakes.

Allowed:
 * 4.9.2-1
 * 4.9.2~pre+1.32e364c4e7
 * 4.10~rc8-1~exp1
 * 4.10~rc8+1.3e11e302a8-1~exp1

Not allowed:
 * 4.10-1

Adjust to linux-support-4.9.0-4

This package uses some code from the linux-support package to generate
files. The way in which this done in the packaging is similar to how the
linux source package is managed.

debian/rules.defs defines a KERNELVERSION which requires you to have the
linux-support-$KERNELVERSION package installed.

For now, update it to 4.9.0-4, since that's the current latest in
Stretch. I'm working on the packaging on a stretch system.

After doing so...
    -$ make -f debian/rules debian/control-real
    [...]
      File "/usr/src/linux-support-4.9.0-4/lib/python/debian_linux/gencontrol.py", line 124, in do_main_recurse
          for featureset in self.config['base', ]['featuresets']:
    KeyError: 'featuresets'

Apparently the newer linux-support requires featuresets to be set. We
simply add it with only the option none, since we don't use it.

debian/patches: Remove 4.8 security patches

I'm preparing a 4.9 or 4.10 release, so no need to keep these.

Import xen_4.8.2+xsa245-0+deb9u1

But, fix the .gitignore while doing so. It was ignoring way too much
(e.g. tree/xen-utils-common) and not ignoring some of the generated
content (e.g. control.md5sum).

The orig tar that belongs to this debian version is created from this
commit in xen/stable-4.8:

    commit 9ba6783e47db71379c5120039b878f605bdf31f3
    Author: Andrew Cooper <andrew.cooper3@citrix.com>
    Date:   Thu Nov 16 11:55:47 2017 +0100

    x86/shadow: correct SH_LINEAR mapping detection in sh_guess_wrmap()