Make localizable variables editable in settings forms

This patch is for now a proof of concept of how to manage localizable variables, which will spawn in settngs forms allowing a different value for every language.
It is meant to be an extension of Gabor's Site settings translation with textgroups patch, but offers a slightly different approach for now. I strongly encourage to go through that patch first. This will also be rewritten and will take advantage of the new variable API if it is finally ready.

The idea:

- Site settings translation with textgroups is a good idea for 'text' variables. These will need a translator, and also they won't affect the system behaviour, so they can be made available for translators.
- There are other variables though that:

• You may want to make localizable, this is, able to take a different value for every language. This is different from 'translatable' in that they're not user interface texts.
• Shouldn't be edited by people without the right permissions, like 'Administer site configuration' for some of them. This is not a permission you'd like to enable for site translators, that may be not technical staff.
• Also, they're not translatable texts, but more low level values, like a image path, or a menu.
• Some samples of these variables are: Site front page, Primary links menu, Theme used, Logo image -when it contains text-, etc...

The solution proposed is:

• Altering these settings forms so selected variables in settings forms may spawn to a different field for every language.
• The site administrator can select directly on the forms, from the list of predefined variables provided by modules with 'hook_locale', which ones will be 'localized' taking a value for each language, and which ones not
• At the low level, a language field is added to 'variables' table. This will allow to store there settings that are not 'translatable texts'.
• The variable loading is done in three stages: first default variables, then localizable variables, then translated text variables. This shouldn't impact performance really as most of the time variables are cached.
• There's a new 'variable_get_default' function that is meant to be used in settings forms, and that will retrieve the default value -or the value for the default language- for this variables, instead of the value for the current page language
• The list of localizable variables is kept in a static variable. It wont be updated permanently until the form is submitted.

Example: site information form

This is the 'Default front page' field. Note the link 'make this setting localizable'.

What happens when you click on that link. Note the link 'change this setting' to get back to previous state. Currently the form is just reloaded with the field extending for each language. Some javascript or ajax may be helpful here though.