Refactor usage of "handle_multiples" for Encode-plugin

Thank you for opening the issue. Although I should remark that the problem arises even by trying to encode simple strings, with or without token substitution, when the Conversion mode is "Base 64 Encode" (basically in that case we have a bug).

Note that if we integrate with the latest Tamper with MR!20, which creates 2 separate actions, Encode and Decode (instead of a single Encode/Decode), we should also limit the Conversion mode options accordingly.

The design around handle_multiples in the tamper module doesn't seem to be a type safe implementation, but we don't seem to be able to get that changed. So, instead of relying on that property, I've changed the approach to call the multiple() method of the tamper plugin to determine, whether we need to provide a string or an array.

This affects the following plugins which declare the handles_multiple property:

• ArrayFilter: requires an array
• Encode: requires a string
• Implode: requires a string
• KeywordFilter: requires a string
• Required: requires a string
• Unique: requires an array

I think, this is reasonable, except for the Implode plugin. From my point of view, that should get the multiple method to return TRUE.