RFC: Replacing ixp4xx-kernel with style-compliant updated linux-ixp4xx

[Rod Whitby <rod@whitby.id.au>]

Now that SRCREV is assumed available in bitbake and OE, it is time to
revisit the ixp4xx-kernel recipes and use modern-day ways of doing things.

To accomplish this, I intend gradually replacing the ixp4xx-kernel
recipes with linux-ixp4xx recipes which more closely follow OE best
practices, and allow for sensible usage of linux-ixp4xx kernel recipes
for all ixp4xx devices (not just those used by nslu2-linux firmware).

For example:

1) Use SRC_URI and SRCREV to pull down the ixp4xx kernel patchset from
nslu2-linux.org, in the same way that linux-openmoko does it, instead of
doing in an nslu2-linux-specific way.

   The main advantages here are that the patchset tarball will be
permanently stored on the downloads mirror, and we can use sane-srcrevs
to control the svn revision of the patches that is used.  This removes
the complaint that OE is dependent upon a third-party svn repository.

2) Use the new linux.inc and remove the stuff that it already does

   The main advantage here is to do things the same way as other linux
recipes do, by including the same linux.inc file.  This also gives us
the opportunity to start to migrate things from linux-ixp4xx.inc to
linux.inc if they are applicable to a wider range of machines (e.g. the
endian patch I submitted earlier today).

3) Remove the python code which automatically determines the SRC_URI

   It's clear that this type of automation is not welcome, and has not
been used recently to it's full effect anyway, so we'll just remove it.

4) Move the arm-kernel-shim stuff out to a separate file or class,
instead of it being always part of ixp4xx kernel builds.  This stuff
should only happen when MACHINE is a variant of nslu2 with a stupid
bootloader, not when you're building for ixp4xx machines which have
sensible bootloaders (either a sensible vendor bootloader, or a
replacement Apex bootloader).  So it's probably a DISTRO thing, rather
than a MACHINE thing.

This will happen over the coming weeks, and I'll make sure the whole set
of linux-ixp4xx recipes and supporting files are in place well before
removing or changing any of the existing ixp4xx-kernel recipes.

Comments welcome.

-- Rod