Add ->decoded_content and a few utility methods.

```perl
  ->decoded_content(?forced_contenttype) => scalar
  ->content_type()   => scalar or undef
  ->content_type_params => arrayref
```
decoded_content optionally takes a encoding field that overrides
autodetection logic and ultimately serves as a shorthand that means
```perl
  ->decoded_content('utf-8')
```
Yields
```perl
  Encode::decode('utf-8', $result->content, Encode::FB_CROAK );
```
Removal of this optional parameter will revert to using content_type and
content_type_params to determine the decoding:

  1. If there is no content-type, there is no decoding.
  2. If the content type is not text/* , there is no decoding.
  3. If the content type contains no parameters after a ';' , there is
     no decoding.
  4. If a parameter in the parameter list matches `charset=(.*)`, $1 is
     picked as an encoding.
  5. If there are multiple such parameters, the rightmost one takes
     precedence.
  6. If there is no such parameter, there is no encoding.

The design of the above is also designed to make it easy for people who
are working with content-types that don't qualify as "text" as per
IANA/W3C, and may have non-standard parameters that are also not
supported in the spec.

For instance, myself, I'm dealing with some upstream declaring
'application/json;charset=utf-8', and I could potentially map that
locally now as:
```perl
  if ( $result->content_type eq 'application/json' ) {
    my $charset = 'utf-8'; # Spec says to assume utf8 anyway
    for my $param (@{ $result->content_params }) {
      if ( $param =~ /^charset=(.*)$/ ) {
        $charset = $1;
      }
    }
    return $json->decode( $result->decoded_content( $charset ) );
  }
```
And that would theoretically work if upstream went insane and changed
'=utf-8' to '=iso-8859-15'.