Set Content-Type on non-file parts

[ixti]

Resolves #5

[abotalov]

It seems to me that this PR:

1. Sets Content-Type for all parts without allowing a user of the gem to create a part without Content-Type.
   But RFC 7578 says that "Each part MAY have an (optional) "Content-Type" header field, which defaults to "text/plain"". So IMO this gem should either:
   • set Content-Type to text/plain for non-file parts
   • not add such header by default
     I think 2nd variant is better as API (see proposed variant below) becomes easier to use.
     Regardless of the chosen solution, a user should be able to say that header shouldn't be added for a part (as this header is said to be optional in RFC).
2. Requires a user to implement a class that responds to #mime_type and #to_s to use the ability of overriding Content-Type.
   IMO a user of the gem shouldn't be required to implement some class. I think a library should provide such class directly.

All in all, I think API should allow usage like (fully backwards-compatible):

form = HTTP::FormData.create({
  :username     => "ixti", # creates a part without Content-Type
  :avatar_file  => HTTP::FormData::File.new("/home/ixti/avatar.png")
})

form = HTTP::FormData.create({
  :username     => HTTP::FormData::Part.new("ixti"), # creates a part without Content-Type, same as previous
  :avatar_file  => HTTP::FormData::File.new("/home/ixti/avatar.png")
})

form = HTTP::FormData.create({
  :username     => HTTP::FormData::Part.new("ixti", :content_type => "application/json"), # creates a part with Content-Type
  :avatar_file  => HTTP::FormData::File.new("/home/ixti/avatar.png")
})

[ixti]

Hm. Then I misunderstood issue description. Agree with your proposals. Will try to fix PR as soon as will have time for that

[abotalov]

@ixti I can implement this feature myself too if you would like me to do it 😄

[ixti]

@abotalov sure

[ixti]

Closing in favour of #10