Add FileUpload

* adds uploads.stripe.com endpoint
* adds support for multipart content
* some interface changes since we now have multiple backends
* bump to 4.0.0 since this is breaking

r? @wangjohn 
cc @metcalf (since it changes some of the interfaces you're relying on)
I've gone back-and-forth on this one. I actually don't think have more than one method is a problem in it by itself. We could change the body to be an `io.Reader` and thus generic between the two, and now we'd end up having to have some util method that converts the `url.Values` to that (as you mentioned) which I didn't have a big problem with if it were the only thing. I do think that passing headers though leaks abstractions. Why should the different clients care about HTTP headers? I think that should be entirely underneath the interface, not exposed. 

The other reason I didn't like the overly exposed interface was because of the complexity of the client. If you look before, the client knew about url, content type, headers, pretty much ignoring everything else being done here. If I know imagine having 10 of those clients, that looks very messy.

Initially I was going to put content type on the `Backend`, but then I quickly realized that it doesn't hold true (for example, if we had everything on api.stripe.com, it would have both url-form-encoded and multipart, so that didn't work either.

Lastly, I'm not convinced that a single method would hold the test for "all the things". And the only way to accommodate for that is to indeed have a very very barebone interface that allows the client to set things loosely.