Don't save configuration data with encryption result

And here's the patch.

Thanks for the feedback, Greg. I should have been more clear. I agree 100% that information needed to decrypt data should be stored with the data. This patch is solely to correct an unwanted side-effect of a commit from a week or so ago. All of the important data from the configuration (method, method settings, provider, and provider settings) continues to be stored, along with options. Storing all of the configuration data in the options is duplicative for the above four items and useless for the others (last modified date of the configuration, for instance).

Here's an example:

Without storing configuration details:

Array
(
    [text] => 5ekj+TWhURB/MYOkZM9Zb1oYot1bX3qmT4O072eckZ1sHBJ2DCqFKBXFp7kxy7k2Ho/nJL4mgAoUkTGMrPZZag==
    [method] => mcrypt_rij_256
    [key_provider] => file
    [options] => Array
        (
        )
    [method_settings] =>
    [provider_settings] => Array
        (
            [path] => ../private/keys
            [method] => file_contents
        )
)

With storing configuration details:

Array
(
    [text] => Muh61Z7A3yqblJjIavTx9qQ9uUX4X/16FBtCcXqUQ8ZiasYZxH2biualT/syuN4N0CmNxDYidkG95hR4CFktMg==
    [method] => mcrypt_rij_256
    [key_provider] => file
    [options] => Array
        (
            [config] => Array
                (
                    [name] => default
                    [label] => Default
                    [description] => The default configuration.
                    [method] => mcrypt_rij_256
                    [method_settings] =>
                    [provider] => file
                    [provider_settings] => Array
                        (
                            [path] => ../private/keys
                            [method] => file_contents
                        )
                    [enabled] => 1
                    [created] => 1418235942
                    [changed] => 1418315171
                )
        )
    [method_settings] =>
    [provider_settings] => Array
        (
            [path] => ../private/keys
            [method] => file_contents
        )
)

It would be preferable to pass the configuration to the plugin's encryption function in a separate $config argument, rather than in $options, but I was reluctant to add a new argument. Looking at it again, though, it would almost certainly not be an issue.

For instance, the call to the encryption function, currently looks like this:
$processed = call_user_func($function, $op, $text, $key, $options);

With the addition of $config, it would look like this:
$processed = call_user_func($function, $op, $text, $key, $options, $config);

If someone has created a new method plugin that has a callback function that doesn't receive $config, it will be ignored. But method plugins that do need it can take advantage of it. This would be cleaner, I think, than shoehorning $config into $options. I'd appreciate any thoughts on the subject.

I created a new issue (Pass configuration to encryption method callback as argument), so I'm closing this one.