Make the '__' pattern for theme suggestions easier to use

HEAD (as well as D6) has a little known feature that theme hooks can define a 'pattern' and code calling theme() can pass an array as the $hook parameter, and this enables specific named overrides of generic theme functions. The views module makes extensive use of this (using '__' as a delimiter by convention), but other than that, few people know about it.

There are now two issues in the RTBC queue for core to take advantage of this: #588148: theme_links() is not really themeable and #634472: Menus cannot be themed differently, which is awesome, because those two issues will enable more theme control of menus and links, and because, they provide a use-case within core, so this '__' feature will become more known and more used.

But, if we're gonna use this in core, and if in core, we're settling on the '__' convention, let's make it easier to use. Instead of code having to call theme(array('links__comment', 'links'), ...), how about letting theme('links__comment', ...) work. It's not that hard for theme() to split by '__'. Also, let's not require theme hooks to register a 'pattern' key to have this default behavior work. We can still leave the 'pattern' key and the $hook=array() option for modules that need more sophistication, but if we're gonna start using the '__' convention in core, let's make using it as simple as possible.

This patch adds no performance overhead in the default case of passing $hook as a string without a '__' (look at where the new code in theme() is placed). With this patch, micro-benchmarking theme(array('links__comment', 'links')) and theme('links__comment') results in equivalent performance: each is a little slower than calling theme('links'), but relative to each other, they're the same. For more benchmarking details, see #588148: theme_links() is not really themeable.

This patch should not hold up those two use-case issues. But if this lands first, they can easily be re-rolled to use it.