Multipart boundary string agnosticism

This will fix #28. I.e. recording and playing back `requests.post(file=...)` multipart requests will now work properly. Hurrah!

The overall effect of this patch is **VCR.py will now consider Requests that differ ONLY by multipart boundaries to be identical**.

## Details

The current implementation is basic: it looks through the request, picks up and remembers declarations of boundaries, then replaces all their occurrences with a very deterministic one (based on a constant, which I've just chosen to be `ffeac16b6e044eec98d4176a95e68663`, a generated GUID. I simply stick a hyphen and a cardinal sequence number at the end of it for every unique boundary declaration I come across: e.g. `ffeac16b6e044eec98d4176a95e68663-1`).

**When recording...**

So let's say VCR.py observes the following multipart message being sent out by `requests.post(file=...)` (snippet from http://www.ietf.org/rfc/rfc2183.txt):
```
Content-Type: multipart/mixed; boundary=070e0bf3cf9042e7970199c939e24ea5
Content-Description: multipart-1

--070e0bf3cf9042e7970199c939e24ea5
  Content-Type: text/plain
  Content-Disposition: inline
  Content-Description: text-part-1

  Some text goes here

--070e0bf3cf9042e7970199c939e24ea5
  Content-Type: multipart/mixed; boundary=3f38b2baea134e97842b3b41793f1a4b
  Content-Disposition: attachment
  Content-Description: multipart-2

  --3f38b2baea134e97842b3b41793f1a4b
    Content-Type: text/plain
    Content-Disposition: inline
    Content-Description: text-part-2

    Some more text here.

  --3f38b2baea134e97842b3b41793f1a4b
    Content-Type: image/jpeg
    Content-Disposition: attachment
    Content-Description: jpeg-1

    <jpeg data>
  --3f38b2baea134e97842b3b41793f1a4b--
--070e0bf3cf9042e7970199c939e24ea5--
```

VCR.py will now **replace the two randomly generated boundary strings** with a **couple of deterministic boundary strings derived from a constant GUID**:

Replacements throughout `header` & `body`:
`boundary=070e0bf3cf9042e7970199c939e24ea5` -> `boundary=ffeac16b6e044eec98d4176a95e68663-0`
`boundary=3f38b2baea134e97842b3b41793f1a4b` -> `boundary=ffeac16b6e044eec98d4176a95e68663-1`

The resulting request `body` and `headers` are then hashed along with `host`, `port` ... etc., and the whole bunch of data  in the cassette is serialised into a `.yaml` file. Great!

The hash is important as it serves as our lookup key.

**When playing back...**

We run EXACTLY the same `requests.post()` method. Aw, shucks; this time, `requests` would have created a new request which looks identical to the original request EXCEPT with different boundary strings... this would cause VCR.py to think they were different requests, and cause a cassette / cache miss. This means, EVERY time `requests.post()`, we hit the network. Not good.

Worry not! With this pull request, VCR.py actually mashes the boundary strings back into determinism again before proceeding checking the cassette / cache for a canned response:

Replacements throughout `header` & `body`:
`boundary=2a2017189d7b45f8af6db3b3f48e71cc` -> `boundary=ffeac16b6e044eec98d4176a95e68663-0`
`boundary=6f8b26dd54264907ad8fc07948520c45` -> `boundary=ffeac16b6e044eec98d4176a95e68663-1`

Now the the `vcr.Request` objects look the same; they hash the same too. Cache hit! Problem solved.

Talk about [onto relations](http://en.wikipedia.org/wiki/Surjective_function), eh?

**Caveats...**

Of course, this new implementation means that recordings of multipart requests submitted via `requests.post()` are NOT faithful. This could be a problem if there's some existing code that expects randomly generated boundaries.