Refactor multipart/related logic into separate module

[simov]

I just refactored the behavior I proposed here #1283

The isChunked, setHeaders and the build methods can be used outside of this class. The related method just wraps them up, but that logic can be put somewhere else.

The reason why I pass the request instance to each method individually is because I don't think it belongs to that class as a property. I even allow the setHeaders method to modify the instance, so I contradict myself here, I know, but it seemed more logical in this case.

Other than that I really want to see a few more modules out of request before I can decide on the best approach about the instance.

I moved the boundary field into the multipart instance, no idea what was the reason to have it attached on the request instance, since it wasn't used anywhere else.

The related method sets up the self._multipart.chunked and the self._multipart.body properties, and then use them to pipe with request if needed (not the most elegant code, but that will change I guess)

if (self._multipart && self._multipart.chunked) {
  self._multipart.body.pipe(self)
}

[nylen]

Nice work.

Looks like you can get rid of uuid = require('node-uuid') in request.js now, right? Any others?

Other than that I really want to see a few more modules out of request before I can decide on the best approach about the instance.

I'm definitely in favor of attaching the Request instance to these "feature" classes. Logically I think it is a property of the class: each instance of a feature object has a Request that it is acting on, and they're all going to be doing things that require modifying the request state. Passing the instance in to each method is more awkward and I think you'll end up repeating that pattern in a lot of other places.

What's the reason for avoiding this? If you're worried about having lots of places where the request state is modified, it would help to have some well-defined hooks that feature modules can use.

[simov]

I was left with the impression that the uuid module is used somewhere else. Just pushed a version that caches the request instance. Right now the only reliable way to find out all interactions with the request instance in this module is by searching for self.request

[seanstrom]

My comments on #1406 would apply here as well.
Good job 👍