Create a project_package module for packaged install profiles on d.o

One of the components of http://drupal.org/node/596488 (see also http://3281d.com/projects/improve-install-profile-packaging) that we're going to add is something sort of like an update status report for each release of an installation profile, so that everyone can immediately tell if a profile release contains the most up-to-date releases or not (with big nasty red warnings if a profile includes code with security updates available).

To do this, we're going to add another project sub-module called project_package, which keeps track of the release nids of everything included in a package release (e.g. an install profile) so we can do the comparisons and provide this status report table.

This probably sounds related to #102102: Parse project .info files: present module list and dependency information, and in a way, it is. However, this is actually quite a bit different. That effort is about figuring out the dependencies of the sub-items included inside a single project release. This is about remembering what projects are included in a "meta-project". If every sub-module was its own distinct project (e.g. we had both d.o/project/views and d.o/project/views_ui), then they'd really be the same thing, but until then (which may never happen) we need pretty much completely different code and schema to handle these two different cases...

Here's a very primitive skeleton module that has the basic schema defined. I'll be fleshing this out over the next few days, but wanted to open an issue about it so hunmonk can use the {project_package_item} table in some of the parts he's working on.

An initial question occurred to me while putting this together: Once #594704: Allow packaged install profiles on d.o to pull in code from other sources + sites is resolved and profile packages include stuff off d.o, this table here will be insufficient. Should we actually call it {project_package_local_item} with the two nid fields, and then use a whole separate table with a more extensive schema for remote items (stuff we pulled in from elsewhere where we don't have a local release nid to use)?

Anyway, you should apply this patch at the root of the project module, and it should make a "package" subdir with project_package.(info|install|module).