Added Unique Identifier to HttpSM, to aid on debugging

While debugging the plugins we've written, we sometimes had trouble
correlating the log messages to one specific request. That is, suppose
thread 1 was executing plugin A, while thread 2 was also executing
plugin A, but for another request. Then the messages on traffic.out
would be intermingled and separating them was sometimes hard. The same
issue would happen if we wanted to correlate messages from the Core
with messages from the plugin, or when trying to correlate plugin A
messages with plugin B messages for the same request.

The solution we came up with was to patch the HttpSM to generate a
Unique Identifier, and expose it to the plugins. Then we created a
script to grep the traffic.out log for this UUID, resulting in
something like this:

1. Issue request:
$ curl -i --proxy 127.0.0.1:8080 'http://a.com/'
HTTP/1.1 200 OK
...
X-Azion-UUID: a7555903-0939-41ab-bc29-2c02ee80e19a
...

2. Get logs using a script to grep traffic.out:
$ getlog.sh a7555903-0939-41ab-bc29-2c02ee80e19a
======== [Sep 1 21:05:07.394] ========
Client IP: [127.0.0.1].
Current Tier: [Slaves]
Chosen origin server: [127.0.0.1:1025].
Orignal scheme [http]
Orignal host [a.com]
Host set to [www.example.com]. Scheme set to [http]
Sending Request.
Got Response [404]. Falling back.
Current Tier: [Master]
Chosen origin server: [127.0.0.1:1026].
Host set to [a.com]. Scheme set to [http]
Sending Request.
Got Response [200]. Delivering to client.
======== [Sep 1 21:05:07.398] ========


This ID has proved very useful while debugging several issues, not to
mention that it helped us to understand how the Core was handling the
requests, so we thought it could be useful for others, and decided to
create this pull request.

As we understand that not everyone would like to use it, we've added a
configure flag, namely, --enable-uuid, to turn the feature on/off at
compile time. Also, as we understand that this feature is useful for
debugging only, we've added options to records.config that allow it to
be turned off:

CONFIG proxy.config.http.use_uuid INT 1
CONFIG proxy.config.http.add_uuid_to_response INT 1
CONFIG proxy.config.http.add_uuid_to_request INT 1
CONFIG proxy.config.http.uuid_header_name STRING X-Azion-UUID

The first one allows to turn the feature on or off. The second adds
the UUID to the client's response, using the header specified on
uuid_header_name. The third one add this header to the proxy's
request. This last feature is useful when the origin server
understands the ID and logs it on its own logs, so one can correlate
ATS logs for one request with origin's logs for the same request.
If we have the length of the string, we should really use it:

id = std::string(vp, n)

Which leads me to my next though, why use std::string anyway? why not let uuid_export create the char * and just free it when the SM is cleaned up?