Cleaning up contrib/ and tools/

[Peter Maydell <peter.maydell@linaro.org>]

We have a couple of directories in our source tree which have
accumulated things in them that don't really belong there; this is a
proposal to clean up by moving things to more appropriate locations
(as 11.1 work, obviously).

Firstly, contrib/ has a tendency to be a dumping ground for stuff that
we didn't think hard enough about finding a good home for, and for
things in a weird "not really maintained" state. We should either
(a) care enough about something to give it a correct home and to
maintain it, or (b) not care about it, and kick it out of our tree.

Secondly, tools/ exists but is very under-used. I think it should be
for the set of standalone tools that we build if you configure
--enable-tools and which we document in docs/tools.  Currently it
contains two things, one of which doesn't match that idea...

So, starting with tools/:

 * tools/ebpf/ is the source for the pre-generated
   ebpf/rss.bpf.skeleton.h ; it should move to ebpf/
 * tools/i386/qemu-vmsr-helper.c is the source for the
   qemu-vmsr-helper tool; it can stay (should it lose its
   i386/ subdir ?)
 * the tools which currently are in the top level directory
   should move into tools/:
    - qemu-bridge-helper.c
    - qemu-edid.c
    - qemu-img.c
    - qemu-io.c
    - qemu-keymap.c
    - qemu-nbd.c

And for contrib/, easy ones first:
 * contrib/vhost-user-{blk,bridge,gpu,input,scsi} move to tools/
 * contrib/elf2dmp moves to tools/
 * contrib/ivshmem-client and contrib/ivshmem-server move to tools/
 * contrib/plugins moves to plugins/plugins (or a different subdir
   name of your choice)

For contrib/, ones I'm less sure about:

 * contrib/vmapple/uuid.sh is a one-liner; we should either commit to
   having this, by giving it a better name and documentation and
   installing it in 'make install', or else junk it and have
   docs/system/arm/vmapple.rst give you the plutil command and tell
   you to run it directly.
 * contrib/gitdm moves to scripts/ ? It's just config data for
   generating statistics about patches, so with other
   developer-related stuff makes sense.
 * contrib/systemd -- we don't do anything with these (e.g.
   'make install' ignores them), so I am sceptical about their
   usefulness. We could drop them, or move them to scripts/, or put
   them in tools/ and qga/ with the tools that they are systemd
   scripts for.

Then we can delete contrib/ entirely.

(scripts/ is also in danger of being "miscellaneous dumping
ground", of course. I have tried not to suggest it as the
destination when I could think of an alternative.)

-- PMM