Enhancements to simplify creation/maintenance of dkms packages

For work within Canonical, have a framework for creating DKMS deb packages - auto-generates dkms.conf and other packaging. Does not use dh_dkms. Aim is to make this public and improved.

David Henningson uses a variant to create an Alsa Crack-of-the-day DKMS snapshot dkms package via a recipe (https://code.launchpad.net/~ubuntu-audio-dev/+recipe/alsa-driver-daily) which merges dkms packaging with the upstream ALSA source.

The existing framework can create FISH packages (Specific to Dell installation process), which has been stripped out of the following branch, showing the existing framework: bzr branch lp:~townsend/+junk/auto-dkms-framework

Framework currently has a script to determine what the .ko files produced are. It may be possible to move this logic into dkms.

For the ALSA dkms package, extra logic is necessary for fetching source etc.. It would be good if the framework were flexible enough to facilitate this, therefore we should consider some sort of plugin option to allow this sort of extra processing. E.g. David's specific can be handled by including his make rules into main Makefile

Could be useful to check dkms.conf for errors, but as files become auto-generated this may be less important.

Agreed Aims:
- incorporating dh_dkms
   openafs in Ubuntu uses dh_dkms
- merging smarts from the framework into dkms package itself (e.g. the script to determine which modules are created)
   * follow dh model for helper scripts, create man pages too
- potentially creating dkms.conf from within dkms itself in the simple scenarios
- Remove non-functional OBSOLETE_BY directive in next dkms version and when framework is merged
- Document and publish new workflow: blog.canonical.com?