Do not special case disabled admin theme

Issue Summary

I realize I suggested this grand hack late in the Drupal release cycle at http://drupal.org/node/192779#comment-661039 and committed these special cases in #192779: Don't show disabled themes on blocks settings page and #201577: show admin theme on page admin/build/themes/settings, but this was one very bad idea.

The original issue as I understand it is that if the admin theme is *enabled*, it can be selected by those users who have the permission to select themes. And this is not desired. So the D6 "solution" was to let the admin theme "work" while being disabled (so you can configure blocks and its settings even though it is disabled). So what's an enabled theme really boiled down to who you ask. If the end user, it was the themes you've set enabled. If Drupal's blocks and themes subsystem, it was the enabled themes plus the admin theme. But what is dangerous is that other subsystems of Drupal like update_status do not have this special casing for admin themes, and when disabled, they are just considered disabled. So if you use a contributed admin theme, update status will never tell you if you have a security update to it, your site will keep being vulnerable (and having your *admin* theme vulnerable can be quite an issue).

So we can continue sprinkling Drupal with special casing of disabled admin themes (more hacks), but in reality we should just fix our mental model. We should raise the question: what does enabling a theme means?

- You can configure its own settings
- You can configure blocks for it
- You can pick it as an admin theme
- You get update status reports about it

Drupal 6 also used to say "- Your users (with appropriate permissions) can pick this theme", but due to #292253: Remove the per-user themes selection from core this is not present in Drupal 7 anymore. However, if we'd consider user theme selection in core, the solution is still not to let the admin theme be disabled, since all the above and other theme related features need ugly special casing. Instead, we should fix the user theme selector then to not include the admin theme. Or even better, just have a configuration screen to pick which themes are available to users, so the above list would be extended with:

- You can pick the theme as one of the user selectable themes

This would map to sites where modules like themekey are used to switch themes based on sections. Maybe not all of those themes would the site owner expose to users. While we can exclude the admin theme, the more generic use case of themekey + user specific theming is impossible to infer programatically.