Attempt to decode Name/Password from Basic Auth as UTF-8

[PJaros]

and cope with the fact that curl (tested on 7.19.7 and 7.56.1) and google-chrome 63.0.3239.108 will send 'UTF-8' encoded strings within the base64 encoded basic auth string.

Attempting to send charset in the 'www-authenticate'-header was ignored by Firefox 57.0.2 (32-Bit), curl 7.56.1, Google-Chrome 63.0.3239.108, Internet Explorer 11.786.15063.0 and Edge 40.15063.674.0. So RFC-7617 is beeing ignored as of 2018-01-01 from those browers.

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
  Bug fix

• What is the related issue number (starting with #)
  CherryPy will allways decode basic authentication information with ISO-8859-1 #1680

• What is the current behavior? (You can also link to an open issue here)
  Name/Password will allways be decoded with ISO-8859-1

• What is the new behavior (if this is a feature change)?
  This will try to decode name and password as UTF-8 if possible.

• Other information:

[webknjaz]

I've done some testing and it turned out that Firefox, while trying to use latin1, corrupts the data during encoding in some characters. I've tested with curl:€öäü (login:password) and the data I get after decoding is different at the position of €, all other chars are represented as expected:

ipdb> base64_decode(params)[5].encode()  # corrupted
b'\xc2\xac'
ipdb> '€'.encode()  # valid
b'\xe2\x82\xac

So during encoding inside of Firefox the first two bytes of € are just replaced with some garbage.

[webknjaz]

Closing in favor of #1683