Fix access violation on mac OS X

Hi!

I attempted to use your library on OS X 10.8 and it failed with a bus error when I tried to get the google homepage.

I used `gdb --args node myscript.js` to debug the thing, and get the following stack trace:

```
GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ..... done

(gdb) r
Starting program: /usr/local/bin/node --debug index.js
Reading symbols for shared libraries ++++......................................................................................................................................... done
debugger listening on port 5858
Reading symbols for shared libraries ...... done
LOG: 2012-10-18T15:43:51.506Z: starting...
[cURL 2] Set option 'VERBOSE' to '1'
[cURL 2] Set option 'FORBID_REUSE' to '1'
[cURL 2] Set option 'URL' to 'http://www.nodejs.org'
[cURL 2] perform
* About to connect() to www.nodejs.org port 80 (#0)
*   Trying 165.225.133.150...
LOG: 2012-10-18T15:43:51.508Z: finished...
* Connected to www.nodejs.org (165.225.133.150) port 80 (#0)
* Connected to www.nodejs.org (165.225.133.150) port 80 (#0)
> GET / HTTP/1.1
Host: www.nodejs.org
Accept: */*

< HTTP/1.1 200 OK
< Server: nginx
< Date: Thu, 18 Oct 2012 15:43:51 GMT
< Content-Type: text/html
< Content-Length: 8632
< Last-Modified: Thu, 18 Oct 2012 15:43:00 GMT
< Connection: keep-alive
< Accept-Ranges: bytes
< 
[cURL 2] receive 3996 bytes
[cURL 2] receive 4636 bytes
* Closing connection #0
[cURL 2] receive succeeded.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000100001308
0x00000001001390df in v8::internal::Builtin_HandleApiCall ()
(gdb) backtrace
#0  0x00000001001390df in v8::internal::Builtin_HandleApiCall ()
#1  0x0000371c77d0618e in ?? ()
#2  0x0000371c77dd9700 in ?? ()
#3  0x0000371c77ddc2a4 in ?? ()
#4  0x0000371c77d248c7 in ?? ()
#5  0x0000371c77d11317 in ?? ()
#6  0x000000010015c291 in v8::internal::Invoke ()
#7  0x000000010011a302 in v8::Object::CallAsFunction ()
#8  0x0000000100cc5b01 in NodeCurl::process (args=@0x102) at node-curl.h:328
#9  0x0000371c77f15c7b in ?? ()
#10 0x0000371c77dd9a0b in ?? ()
#11 0x0000371c77dfd381 in ?? ()
#12 0x0000371c77d098ce in ?? ()
#13 0x0000371c77d248c1 in ?? ()
#14 0x0000371c77d11317 in ?? ()
#15 0x000000010015c291 in v8::internal::Invoke ()
#16 0x000000010011a9b0 in v8::Function::Call ()
#17 0x0000000100004d45 in node::MakeCallback ()
#18 0x0000000100004b6a in node::MakeCallback ()
#19 0x000000010001d786 in node::TimerWrap::OnTimeout ()
#20 0x0000000100051caa in uv__run_timers ()
#21 0x00000001000436c2 in uv__run ()
#22 0x000000010004367f in uv_run ()
#23 0x0000000100008d3e in node::Start ()
#24 0x0000000100000d34 in start ()
(gdb) info reg
rax            0x1018012a8	4320137896
rbx            0x100000000	4294967296
rcx            0x1018012b0	4320137904
rdx            0x100f219b4	4310833588
rsi            0x0	0
rdi            0x102	258
rbp            0x7fff5fbff020	0x7fff5fbff020
rsp            0x7fff5fbfef80	0x7fff5fbfef80
r8             0x7fff5fbfef1c	140734799802140
r9             0x7f	127
r10            0x100f4cb10	4311010064
r11            0x100f2406b	4310843499
r12            0x0	0
r13            0x176499f34f61	25720847028065
r14            0x1018012a8	4320137896
r15            0x0	0
rip            0x1001390df	0x1001390df <v8::internal::Builtin_HandleApiCall(v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>, v8::internal::Isolate*)+428>
eflags         0x10206	66054
cs             0x2b	43
ss             0x0	0
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0
(gdb) frame 8
#8  0x0000000100cc5b01 in NodeCurl::process (args=@0x102) at node-curl.h:328
328							curl->on_end(&msg_copy);
Current language:  auto; currently c++
(gdb) print curl
Unable to access variable "curl"
$1 = <variable optimized away by compiler>
(gdb) p curl->on_end
Unable to access variable "curl"
$2 = <variable optimized away by compiler>
```
In an attempt to figure out what was going on with `node-curl.h:328`, I disabled the optimization flag in wscript and rebuilt the project. 

Suddenly, the problem went away, and now it successfully runs the callback. I am unsure exactly why the `O2` switch causes this problem, but I don't see any particular reason to have them turned on, especially when the debugging symbols are left in.