Allow altering settings per editor and field

We've previously had requests for more context in hook_wysiwyg_editor_settings_alter(), specifically which field (FAPI element) the editor will be attached to. The ability to adjust certain editor settings for just a few fields (like their height) has also been requested.

A major problem with running hook_wysiwyg_editor_settings_alter() once per field and editor profile was the huge amount of settings data which would be generated when using several profiles and editing a form with many fields.

To improve the situation, I've added two new hooks, two editor callbacks, and some logic to have three "levels" of settings: globals per editor, per profile, and per field settings. The new hooks are hook_wysiwyg_editor_global_settings_alter() - running once per editor, and hook_wysiwg_editor_field_settings_alter() - running once per field. The new editor callbacks are 'global settings callback', 'field settings callback', and 'profile settings callback' (replaces the current 'settings callback' and takes a different last parameter).

Most of the logic is implemented in wysiwyg_get_editor_config(). It now takes a list of profiles and the current element for which to generate settings. The per editor and per profile settings get cached for multiple fields, but it only returns data relevant to the passed in profiles. The data is returned in pretty much the same structure as Drupal.settings.wysiwyg.configs uses, but it turns out this wasn't optimal for how Drupal merges settings added multiple times. So wysiwyg_add_editor_settings() now takes the same profile list and makes sure no settings get added twice. It works really well together with Better Formats, btw.

I've not touched plugin settings yet, so wysiwyg_add_plugin_settings() still has the same function signature and uses drupal_add_js() as before.

This dragged with it a few other changes, like needing to fetch editor themes without a specific profile (CKEditor can only use one skin at a time, so it needs to be applied globally), so wysiwyg_get_editor_themes() now takes an editor name instead of a profile. I think this makes sense because that function essentially just tells the editor implementation to scan its folder (though that's mostly not implemented) and return found themes, which should not change depending on the settings used.
Because of the changes in this patch, it should be much easier to implement a GUI for selecting the editor theme/skin, or even a GUI for tweaking global editor settings (would be handy for picking the library variant to use as well).

Considering the above functions in wysiwyg.module perform very specific tasks that other modules should not really mess with, and we've never encouraged using anything but the hooks, I don't see a problem with these changes. (Just to be sure, I checked with a bunch of modules that interact with Wysiwyg, and none of them should be affected.)