Protect against mutating frozen strings

[mwrock]

I have seen a few occurence where passing in credential strings that are frozen, usually because they are from environment variables, a can't modify frozen String error is raised from rubyntlm.

In this PR, the altered tests demonstrate this:

Failures:

  1) Net::NTLM::EncodeUtil#encode_utf16le should convert an ASCII string to UTF
     Failure/Error: str = str.force_encoding('UTF-8') if [::Encoding::ASCII_8BIT,::Encoding::US_ASCII].include?(str.encoding)

     RuntimeError:
       can't modify frozen String
     # ./lib/net/ntlm/encode_util.rb:42:in `force_encoding'
     # ./lib/net/ntlm/encode_util.rb:42:in `encode_utf16le'
     # ./spec/lib/net/ntlm/encode_util_spec.rb:7:in `block (3 levels) in <top (required)>'

This PR duplicates the string in decode to ensure the encoding changes occur on a different instance. For encode_utf16le, I simply removed:

str = str.force_encoding('UTF-8') if [::Encoding::ASCII_8BIT,::Encoding::US_ASCII].include?(str.encoding)

which seemed unnecesary given that the next line, which already duplicates the value, begins with the same forced encoding.

[mwrock]

Also see WinRb/WinRM#221

[mwrock]

rebased with #31 to fix travis. Looking to release this and include with a winrm release later today. cc @zenchild and @sneal

[zenchild]

Don't we need to do an assignment here? Otherwise the next line will be against the original object?

[mwrock]

ugh. yes of course

[mwrock]

added reassignment @zenchild

[mwrock]

I tried to find a way to make this blow up if that first encoding was omitted to better catch this in the unit tests but ruby seems very forgiving at least on the strings and encoding I was using

[zenchild]

[mwrock]

Thanks @zenchild ! Will do a release later on.