Allow setting default user-facing skinr settings for page elements in theme

I know the topic of default skins has come up before #549096: Default Skins, but I would like to propose this for D7.

A few things have changed that make this a stronger idea for Drupal 7:

• Region styles -- if you want to use Skinr to do region styling that's fundamental to the design of the theme, then having that not working out the box is a poor user experience
• Layout -- again, especially since Skinr could be used for sidebar & content region widths
• More elements are now regions/blocks, like highlight, footer, etc. Themers have historically been able to control the out-of-the-box output of these because they're printed directly in the theme, but now they are normal blocks, so a skin has to be manually applied.

Also it would be very handy to set a default skin for unique elements, like primary links -- eg. assign a dropdown menu style for a menu_block in the 'navigation' region. If there's basically only one skin in a theme that works for a certain region/block, why not just be able to set it automatically?

A cascading approach, where styles apply from the more general to the most specific, would allow for the widest range of use cases.

I'd propose a syntax like the following, either in the .info file or perhaps a separate defaults file:

skinr[element][block][default][myskin_name][option] = 1
skinr[element][block__user][default][myskin_name][option] = 2

(apply myskin_name option #1 for all blocks, but then option #2 for user module blocks)

The [element] and [default] keys would delineate between where it should be applied vs what skin should be applied.

Here's another example with stacked restrictions:
skinr[element][region__sidebar_second][block__menu][default][skin_system_name][option] = 2

(apply skin_system_name option #2 for all menu blocks in the sidebar second region)

Default skins could be displayed in the admin UI like other modules such as Views or Imagecache do now, where there is a "default" listed which is shown as "overridden" if it has been edited, and could even be reset to default from here.

This feature could also make it possible to address two other common concerns with Skinr:

1. Managing style settings in code
2. More granular Skinr permissions

For #1, this would make it possible (if you wanted to get this granular) to set all skins throughout a site in code. This would address the complaint that all configuration lives in the database rather than in version control.

For #2, it would then be possible to create a Skinr permission that allows changing styles, but not overriding defaults. So a user with just this permission could only change skins that had already been overridden (or did not have a default?), but would not have permission to edit a skin set to the default. This way developers could control which skins could be administered by the client or some other level of user without giving full Skinr permissions.