Clean up Hosting 'Features'

In the dev/features_cleanup branch, I've added a 'required' fieldset to the features form, and added features for the modules that were missing them, all of which are required. My reasoning here is to make things more consistent and discoverable.

I also discovered an odd behaviour when enabling a feature that has dependencies. We get the following status message:

Enabling hosting_nginx_ssl, hosting_ssl, hosting_nginx modules
The configuration options have been saved.

Along with the following error:

You cannot disable hosting_nginx because hosting_nginx_ssl depends on it

Also, we're polluting the variables table with a bunch of useless entries, since we do this:

    variable_set('hosting_feature_' . $feature, $value);

when system_settings_form_submit() already does the same thing, but without the 'hosting_feature_' prefix. We could clear up this duplication by adding that prefix to our form array keys.

I added an update hook to cleanup this junk from the variables table.

Documentation for enable/disable callback functions was wrong. I fixed the docs, and provided examples. We should test for this, at some point too.

Re. #1, we seem to be trying to be too clever, and enable/disable in the same foreach loop. I think we should build our array of modules to enable/disable first, along with dependencies. Then we can enable/disable those, and run our callbacks.

One idea that came up in discussion, was to sub-divide the fieldsets by the module groupings on the modules page. That way, the existing fieldsets, which represent the a status remain, but we have flexibility to group together features within (i.e. devshop, aegir_contrib, etc.)

It's a bit presumptuous for us to assume that all aegir contrib modules are "experimental", isn't it?

'Experimental" is just the default. It can be overridden by just listing your relevant feature(s) in the 'optional' group, or even 'required' (though I wouldn't recommend it).

I've merged my dev branch into 6.x-2.x.

We now display dependencies, and lock features required by others (just like on the modules page). I also added grouping by module package, along with a minor update to Eldir to distinguish a fieldset within fieldset. Finally, I fixed up the enable/disable logic.

On a related note, I've mentioned before that I think our Hosting Features functionality should just be replaced by Features, but I think the two issues are orthogonal. While Features would make exporting other Drupal config easier (Views is a good example), I think Hosting Features still has its place. First off, it gives us a 'administer hosting features' permission, that makes it possible for a user not to have to have full site admin access to manage Aegir features.

Secondly, we may want to consider implementing either/or-type dependencies. Right now, to Nginx you need to enable Apache support, and likewise Apache SSL support for Nginx SSL. Eventually, we'll probably have #585796: postgresql backend support, and still need MySQL enabled (if if we fix #548882: PostgreSQL frontend support). While we'd need to pull Apache out of Web Server, and so on, I think it might be worthwhile.

I had added #2013719: Separate default implementations from services, as a follow-up to my second argument. I have reconsidered the need for either/or dependencies, but I'll document it in that (active) issue.