Don't filter response hash components

It's risky (and unnecessary) to apply check_plain() filtering to the data components of the transaction response hash, as the module currently does. The SHA version of the hash now includes customer-entered data, and some of this potentially contains characters that would be encoded by check_plain(). The module should instead use the raw string values returned by Authorize.Net, as these presumably were used to generate Authorize's version of the hash value.

Patch to follow.