[coreboot] release engineering process

[ron minnich]

I'm fine with regular releases with one proviso: if we announce a
release date, and a version, and a test, then we drop all boards that
are not working as of that date. It's git, we can bring them back. But
a release to me means that everything I find in src/mainboard/* is
working for that release. If we don't achieve that goal then a release
(to me) has no meaning.

Or else we add a level to mainboard:
src/RELEASE/mainboard
or we drop the mainboard as a name, and just have src/<release>/vendor/etc.
and you can easily see where a mainboard is for a given release.
src/2015.1/google/peppy tells you that the peppy was known to work as
of the 2015 Q1 release. Bringing a mainboard forward works like this:
git mv src/2015.1/google/pepppy src/2015.2/google

It does not move forward unless we have a passing test. We need to
define a passing test. The ubuntu one looks as good as any.

But we need a process for killing old junk, and a release process is
as good as any.

ron