Rack rack

Please find yet another approach to force_encoding params treatment in ruby1.9.1.

#48 spawned a great discussion. It seems like standards can be broken and browsers can misbehave. But I'm not sure why we should get params encoded in ASCII when specified charset and actual charset do match (i.e. cases when browsers did their work well - this happens pretty often with utf-8).

An additional feature is the env['rack.force_content_charset'] option which can be used to override request header setting, so that middleware can do the trick described by naruse (http://rack.lighthouseapp.com/projects/22435/tickets/48-rackutilsun...)

Utils::unescapse was patched so it now preserves encoding of input string for the result (was not the case for strings containing hex encoded parts).

This patch takes care only of body encoded parameters (POST), because charset parameter of Content-Type describes body. I'm not sure how I should treat params that come from URI query tough. Any comments are welcome.

BTW I had an alternative implementation which performed set_encoding on env['rack.input']. I liked the idea of having the whole body encoding set according to request header and then naturally spread it everywhere. Although it didn't break any existing tests, it still seemed to be unsafe for the code parsing multipart form submissions. And at the same time that parsing implementation does not preserve input stream encoding in resulting hash, so explicit force_encoding calls would still be required. So I've dropped that option for now.