convert theme.inc, unicode.inc, and xmlrpc.inc to use new static caching API

Here we go.

Oops. Missed a call to reset list_themes(). The tests should now pass.

Please do not remove $reset/$refresh parameters and only call drupal_static_reset() from test functions.

I'm confused by Dries' comment in #5 - why are $reset/$refresh parameters necessary now that we can use drupal_static_reset()? All the extra parameters in arbitrary order indicate bad code design and bad developer experience, so eliminating them should be a good thing. Also, I see nothing in the docs at http://drupal.org/node/224333#static_variable_api or in the original issue to indicate that drupal_static_reset() should only be called from within test functions, and http://api.drupal.org/api/function/drupal_static_reset/7 also shows that the function is called throughout core, not just in the testing system. Furthermore, drupal_static_reset() is a common API and I think that developers should be encouraged to use it rather than calling functions with an arbitrary list of parameters. Please explain your reasoning here.

@cwgordon7
See #422370-17: Revisit and convert mail.inc, module.inc, pager.inc to use static caching API and the following comments. In short, Dries thinks we shouldn't use them, many others (me included) think we should.

My arguments *for* using drupal_static_reset() are:
- drupal_static_reset() cannot do more than a $reset parameter, it can only clear the static cache. If more complex stuff needs to happen, function x can re-initialize it's stuff when the static cache has the default value.
- We have currently different ways to pass a reset flag for example an optional argument $reset (on the first, second, third, n-th position) or a key 'type' set to 'reset' in a $options array. With drupal_static_reset() there is only one single way to reset something: drupal_static_reset('function_name')
- Many functions will automatically regenerate the data when the reset flag is true, for example module_list() and node_get_types(). However, this is often unecessary, we may just want to delete the static cache and only have it loaded again when someone tries to access it.

Another thing, Dries argument "It's really messy for one function to mess with another function's innards" is not a argument against drupal_static_reset() (because that can't do anything except resetting), but against drupal_static() itself, which can very well do that. drupal_static() can actually do *much*. For example, it would allow contrib modules to provide different caching mechanisms for drupal_lookup_path() and similiar functions *without* the need for dynamic includes, handlers* and so on. Simply by inserting data into the internal static variable (in hook_init, for example) and loading & storing the updated data again in hook_exit. AFAIK there are some functions that allow that kind of stuff with another type of special arguments , that is another thing we can remove in favor of drupal_static(). Of course, this could also lead to very unexpected behavior...

* I'm not saying that we don't need them...

Heh, I even read and commented on that issue... should have remembered that. However, it appears that after Dries' comment in #17, the issue was discussed, and the general consensus appears to have been that using drupal_static_reset() is fine.

I thought using drupal_static_reset() was the agreement as well. Maybe we need more discussion about the static caching API and how to handle resetting these vars?

Rolled patch against latest version of D7.
The patch failed against #369409: Move block theme definition from system module to block module, which moved template_preprocess_block() from theme.inc to block.module.

Should work now.

In system.admin.inc, should we create a list_themes_reset() to wrap up drupal_static_reset('list_themes')?

-  list_themes(TRUE);
+  drupal_static_reset('list_themes');

Not sure why it failed, but I've rerolled it against HEAD.

Ok. I wasn't sure where to draw the line between documenting drupal_static_reset use with wrapper functions and avoiding verbose (and, due to the increased function calls, arguably less efficient) code.

This patch includes a few comment changes. I forgot to remove an @param directive for the $refresh var that this patch removes. The rest of the changes are additions and removals of blank lines within the function comment blocks. A couple of the comment blocks lacked a blank line between the function description and the @param/@return directives. Others included a blank line between the group of @param and the group of @return directives; most other comment blocks have no blank line separating them.

Rerolled.