Added support for custom content_type and signature_type (#111)

[jjbarr]

This is my attempt at implementing the changes discussed in #111. Please let me know if I need to do any additional fixes.

[jesselawson]

This looks great! Would you mind if I propose some readme organization changes now that we have these additions?

[jjbarr]

Fine by me!

[jedisct1]

Friendship among coworkers is great.

[jedisct1]

I'm not sure that tieing a content_type to a key is the best way to proceed, as a key can be used to sign different content types.

What would be alternatives? Store this in Claims, maybe?

[jjbarr]

It would get pretty awkward to store it in claims, since everything else in there just directly serializes to/from the claims section of the JWT.

We could have for_content_type/for_signature_type wrap the key in a struct that has its own sign /authenticate (as is appropriate for the type) method that attaches the header? That feels like a slightly cleaner approach to me.

[jjbarr]

So to sketch this out, each <algorithm>Like trait would get a sign_with_header_options()/authenticate_with_header_options() method. The methods for_content_type and for_signature_type would be on HeaderOptions, existing sign/authenticate methods would then become, for example:

fn sign<CustomClaims: Serialize + DeserializeOwned>(
    &self,
    claims: JWTClaims<CustomClaims>,
) -> Result<String, Error> {
    self.sign_with_header_options(claims, default::Default())
}

[jjbarr]

I finally had some time available, so I took a crack at implementing an API similar to what I described above. I pushed it to this branch, although maybe it should be its own pull request?

In any case, this is a bit of an experiment, so I'm entirely fine reverting it if you decide this isn't the way you want this done.

[alterstep]

sign_with_custom_enevelope?
-> more generic

[alterstep]

or only sign_with_options?

[jjbarr]

sign_with_options seems cleaner, I can change that.