Split out site specific packaging code into custom modules

Now that we've got the packaging script ported (in CVS HEAD) to Version Control API, it might make sense to go a bit further and get rid of the drupal.org dependencies as well. Most of that code is in the package_release() function inside of an if ($is_core) { ... } or if ($is_contrib) { ... } block, and includes both translation release functions as well as the search and adaptation of .info files. Also the $license and $trans_install global variables are not required for a generic packaging script.

Sites that don't deploy Drupal modules obviously won't make much use of that code, it might even get in the way. As the package-release-nodes.php script has a fully bootstrapped Drupal environment at hand, it could easily make use of hooks and callbacks from third-party modules - the main issue is how to pass and alter the given variables so that the "release customization" hooks/callbacks are intuitive to understand and not too many.

Tasks that release customization modules might do (current d.o functionality):

• Determine the name of the top-level directory - e.g. core: "drupal-6.9" - which should be the default imho -, or contrib: a plain "versioncontrol" as directory name (so that updating the modules is less a hassle for admins).
• Insert additional files into the release package (e.g. LICENSE.txt), or remove files that are only interesting to developers.
• Specify whether to package the project directory wholesale (= default) or just a list of its files (D6 translations).
• Optionally pass a list of files in the project directory to be packaged, instead of packaging all files in there (= default).

Sites other than drupal.org might want to provide different customizations, such as automatically including the latest version of documentation files in certain packages, or invoking the build system to ease installation (e.g. have autotools create the ./configure script).

It should also be noted that not all projects in a repository will necessarily follow a single packaging scheme - on d.o, there's already four different ones (core, D6 translations, pre D6 translations, contrib modules/themes). Thus, make sure to pass the necessary context to the customization functions, probably the whole jazz (or nearly so) that package_release() has access to.